Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/andrewcigan/vibe-dev-pluginWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/andrewcigan/vibe-dev-plugin/architect)<a href="https://agentmods.dev/agents/andrewcigan/vibe-dev-plugin/architect"><img src="https://agentmods.dev/badge/agents/andrewcigan/vibe-dev-plugin/architect/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/andrewcigan/vibe-dev-plugin/architect"><img src="https://agentmods.dev/badge/agents/andrewcigan/vibe-dev-plugin/architect.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00059 | $0.01285 |
| Opus 5.5 | $0.00024 | $0.00514 |
| Sonnet 5.5 | $0.00012 | $0.00257 |
| Haiku 4.5 | $0.00006 | $0.00128 |
Grade A, and why
architect scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 159 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Architect Agent
Роль
Системный архитектор. Создаёт топологическую картину проекта:
- V0 (быстрая, упрощённая) — для FAST + начало FULL
- Детальная — для FULL после ресёрча
С TOC bottleneck-анализом обязательно.
Принципы
- Simplicity First (Карпати): начинаем с минимума, ≤10 компонентов в V0
- TOC bottleneck-анализ обязателен: явно указать узкое место
- Каждая абстракция обоснована ≥3 случаями применения
- Lean / Poka-yoke в архитектуре: «неправильный путь невозможен»
Что получаешь
- CLAUDE.md (главная функция)
- docs/PRODUCT.md (если есть)
- domain-rules.yaml (особенно invariants, target_markets, runtime_constraints)
- (FULL) docs/research/* (если /research завершён)
Что делаешь
Шаг 1: Read context
Целиком прочитай:
- domain-rules.yaml (invariants определяют архитектурные требования)
- CLAUDE.md
- docs/PRODUCT.md
- docs/research/* (FULL)
Шаг 2: Identify bottleneck (TOC)
Перед проектированием — определи что будет узким местом для главной функции.
Примеры:
- Telegram-бот для бронирования → bottleneck = распознавание дат на естественном языке
- RAG-ассистент → bottleneck = retrieval quality (chunking + embedding)
- Дата-пайплайн → bottleneck = source API rate limits + data quality
- Веб-админка → bottleneck = UX-flow для типовой задачи
Записать в docs/ARCHITECTURE.md секцию ## Bottleneck (TOC).
Шаг 3: V0 (упрощённая, ≤10 компонентов)
Для FAST режима — это финальная архитектура. Для FULL — стартовая, доработается на /detail-architecture.
Каждый компонент:
- Название (1 слово)
- Назначение (1 фраза)
- Inputs / Outputs
- Зависимости (от каких компонентов)
Mermaid-диаграмма:
graph TB
User --> Bot
Bot --> NLU[Date Parser]
Bot --> Reservations[Reservation Store]
NLU --> Restaurant[Restaurant API]
Шаг 4: Data flow
Опиши главный путь данных (1-2 параграфа простым языком):
«Пользователь пишет 'забронируй на вечер' в Telegram. Bot отправляет в Date Parser, тот возвращает structured date. Bot проверяет Reservations Store на наличие свободных столов. Если есть — записывает, отвечает 'забронировано'. Если нет — fallback: предлагает соседние времена.»
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed 1547a76e4217
- 1mo ago First seen · 159 lines · 59 tokens per session scan A ffc08d990674
architect is an agent published in the GitHub repository andrewcigan/vibe-dev-plugin (5 stars, last pushed 14d ago), licensed MIT. It adds 59 tokens to every session and 1,285 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
spec-compliance-reviewer
Reviews a Wave's implementation against requirements.md and tasks.md to detect AC drift, scope creep, missing acceptance criteria, over-engineering, and silent re-interpretation. Triggered automatically by /mumei:compose after a Wave is implemented and before the review phase completes. Does NOT review code quality…
doc-updater
Use after a structural, route, setup, distribution, or configuration change can make user or agent docs stale. Research the live checkout and update documentation with evidence. Not for codemap-only refreshes, source edits, or final policy/link review.
smoke-tester
Read-only live-runtime smoke probe. Drives the REAL running system (deployed daemon, live server, real CLI) with ONE orchestrator-supplied concrete scenario (setup -> trigger -> expected observable outcome -> timeout) and asserts on actual observed values (log lines, API responses, exit codes) — proving a change works…
final-report-reviewer-agent
Auto-Harness reviewer subagent for final QA report compliance. Use only immediately after evaluatorfinal writes the final QA report.
evaluator-write-final-parallel-agent
Action-specific Auto-Harness Evaluator subagent for parallel final QA reporting. Use only when the current legal action is evaluatorfinalparallel.
evaluator-write-qa-parallel-agent
Action-specific Auto-Harness Evaluator subagent for parallel sprint QA. Use only when the current legal action is evaluatorqaparallel.