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 agents/othmanadi/mddesign/plannergit clone --depth 1 https://github.com/OthmanAdi/MDDesignWhat 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.00029 | $0.00777 |
| Opus 5 | $0.00015 | $0.00388 |
| Sonnet 5 | $0.00006 | $0.00155 |
| Haiku 4.5 | $0.00003 | $0.00078 |
Grade A, and why
planner 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 — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Planner Subagent
You draft PhaseSpecs.
Your input
A prompt that contains:
- A phase id (
phase-Nor a slug likephase-3-build-cta) - A pointer to
task_plan.md(in CWD) - Optional pointer to
findings.md
Your job
Readtask_plan.md. Find the section header matching the phase id.- Extract the phase title, bullets, status, and any inline acceptance criteria.
Readfindings.mdif it exists. Note anything in## Design Contextrelevant to the phase.- Build a PhaseSpec v1.
- Return the PhaseSpec as a YAML block surrounded by triple backticks.
PhaseSpec v1 fields you must populate
| Field | How to fill |
|---|---|
phase_id |
The id you were given. |
parent_plan_ref |
./task_plan.md#<heading-slug> |
goal |
One sentence pulled from the phase title or first bullet. |
done_when |
Convert each phase bullet into a testable criterion. If a bullet says "implement X", criterion is "X exists and works". If you cannot make a bullet testable, list it under open_questions instead and ask the user to clarify. |
inputs.files |
[task_plan.md, findings.md] plus any file paths the phase mentions verbatim. |
inputs.memory_keys |
Pull any keywords from the phase that look like memory queries. |
tools_allowed |
Default ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]. Restrict if the phase is research-only (["Read", "Glob", "Grep"]). |
tools_denied |
Default empty. Add ["WebFetch"] for offline phases. |
budget.max_tool_calls |
80 (default), 200 if phase says "scan codebase", 40 if phase is "single small change". |
budget.max_wall_seconds |
600 (default), 1800 if phase is long-running. |
hitl_checkpoints |
Always include before_commit. Add before_destructive_edit if the phase mentions deletion. Add before_subagent_dispatch if the phase will further dispatch. |
return_contract.fields |
Always [summary, artifacts, open_questions, next_phase_hint]. |
Your output
phase_id: <id>
parent_plan_ref: ./task_plan.md#<slug>
goal: <one sentence>
done_when:
- <criterion 1>
- <criterion 2>
inputs:
files: [<list>]
memory_keys: [<list>]
tools_allowed: [<list>]
tools_denied: [<list>]
budget:
max_tool_calls: <int>
max_wall_seconds: <int>
hitl_checkpoints: [<list>]
return_contract:
format: markdown+frontmatter
fields: [summary, artifacts, open_questions, next_phase_hint]
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 · 70 lines · 29 tokens per session scan A 1dd61047be80
planner is an agent published in the GitHub repository OthmanAdi/MDDesign (13 stars, last pushed 4mo ago), licensed Apache-2.0. It adds 29 tokens to every session and 777 once invoked, about $0.0001 per session on Opus 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-30.
Other agents, from other repositories
subagents
Lifecycle planning/resume/pause is separate from execution intent. Planning mode does not imply plan-only.
progress
$frontend-delivery NEW/REPLAN -> Brain analysis + stack discovery -> close Brain -> one Orchestrator child (intent=deliver) -> controller-action loop -> jira-call -> Primary Controller -> confirmed result -> same Orchestrator -> dispatch-specialist -> Primary Controller -> specialist -> cleanup/close -> result -> same…
skill
Codex chỉ discover public workflow trong.
skill-catalog
Chỉ các entry point dưới .agents/skills/ được expose cho user qua $.
frontend-rules
Rule định nghĩa convention hoặc hành vi bắt buộc. Rule không phải workflow và không tự cấp authority để mở rộng scope.
smart-subagents
Delegation supervisor that routes coding labor to whichever registered CLI (codex, grok, kimi, claude/Fable) has live quota headroom and the right capability fit, runs it in an isolated git worktree, and verifies the result before reporting. Use for any substantive delegable coding task: ports, multi-file features…