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.
npx agentmods add commands/aidemd-mcp/server/plangit clone --depth 1 https://github.com/aidemd-mcp/serverWhat 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 | $0.00000 | $0.01072 |
| Opus 5 | $0.00000 | $0.00536 |
| Sonnet 5 | $0.00000 | $0.00214 |
| Haiku 4.5 | $0.00000 | $0.00107 |
Grade A, and why
plan 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 2d 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 — 32 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/aide:plan — Plan Phase
Agent: This command is executed by the
aide-architectagent.
Translate the intent spec into a step-by-step implementation plan. Output: plan.aide (the build recipe). The spec may be in one of two shapes: Shape A (synthesize ran — body sections filled, sibling brief.aide exists) or Shape B (synthesize skipped — frontmatter only, no brief.aide; the orchestrator's delegation prompt carries the user's implementation context as the architectural input). For Shape A, UPDATE brief.aide as planning surfaces new commitments. For Shape B, CREATE brief.aide only if planning surfaces commitments worth recording. See plan.aide spec and brief.aide spec.
Checklist
- Read the intent spec (
.aideorintent.aide) in the target module. Frontmatter is always required. Body sections are present only in Shape A. - Identify the shape:
brief.aideexists → Shape A;brief.aidedoes not exist → Shape B. For Shape A, read the siblingbrief.aide— its commitments are the current architectural state your plan must honor or deliberately retire; its open questions are decisions awaiting your settlement. For Shape B, the orchestrator's delegation prompt carries the user's implementation instructions verbatim — that's your architectural input. - Pull the coding playbook from the brain using the
study-playbookskill — naming conventions, folder structure, patterns to follow and anti-patterns to avoid - Scan the target module and its neighbors to understand what already exists — existing helpers to reuse, existing patterns to match, folders already in place
- Write
plan.aidenext to the.aidespec with:- Frontmatter:
intent— one-line summary of what this plan delivers ## Project Structure— the complete annotated folder tree of the module, rooted at the scope directory. This IS the recipe blueprint — every plan includes it unconditionally, whether greenfield or additive. The implementor must never figure out the module's structure; that is the architect's job. Every file that will exist after execution appears in the tree, annotated with what it does and its function signature (parameters and return type). For additive plans, mark which files are new vs. existing..aidespecs go next to orchestrators, not helpers.## Plan— checkboxed steps (the "cooking order" for the recipe above):- Each step references files from the Project Structure tree
- Steps may reference
brief.aidecommitments by number ("honor commitment #11") - Which existing helpers to reuse instead of writing new ones
- Sequencing — what must exist before the next step can start
- Tests to write for each behavior the spec's
outcomes.desirednames
## Decisions— architectural choices made: why X over Y, naming rationale, tradeoffs
- Frontmatter:
- Shape A (brief exists): Update
brief.aide(do NOT overwrite — the strategist authored it). Shape B (no brief): createbrief.aideonly if planning surfaced commitments worth recording; if the plan + spec frontmatter fully describe the module, do not create an empty file. Sections (when the file exists):## Commitments— numbered commitments. Type shapes, function signatures, exact strings, schema cardinality, marker tokens, enumerations of accepted values. Numbers persist across edits — gaps stay when commitments are removed; new commitments append## Cross-module contracts— what this module exposes/consumes vs. neighbors## Open questions— design decisions deferred to build, cleared as they are answered downstream
- No implementation code in any file — no function bodies, no algorithms as code. Architectural contracts (types, signatures, exact strings, schema details) belong in
brief.aidewhen one exists, otherwise in the plan step bullets. If an implementor would have to invent it, name it explicitly. If the playbook covers it, put it in the plan step's Read list. - Every plan step must be traceable back to a line in the
.aidespec, abrief.aidecommitment, or a rule in the coding playbook. If a step has no source, cut it or find the rule that justifies it - If the spec is ambiguous, stop and escalate back to the spec writer (via the orchestrator) rather than inventing an answer
- PAUSE for user approval. Present BOTH
plan.aideand the updatedbrief.aideand do not proceed until the user approves them. Iterate if the user requests changes - Hand the approved plan + brief to the implementor via
/aide:build
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.
- 2d ago First seen · 32 lines · 0 tokens per session scan A cc930e728fbe
plan is a command published in the GitHub repository aidemd-mcp/server (3 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,072 tokens. 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 commands, from other repositories
design-brief-builder
Generate Design-Brief.md through structured design interview.
analyze
在任务生成后，对 spec.md、plan.md 和 tasks.md 进行只读的一致性与质量分析。.
implement
读取并执行 tasks.md 中定义的全部任务，完成实施计划。.
review-pr
Fetch a pull request diff, run code-reviewer analysis, translate findings to owner voice, and post a single batched inline GitHub review.
checklist
基于用户需求为当前功能生成自定义检查清单。.
example
Example command that demonstrates extension functionality.