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/reviewergit 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.00034 | $0.00481 |
| Opus 5 | $0.00017 | $0.00241 |
| Sonnet 5 | $0.00007 | $0.00096 |
| Haiku 4.5 | $0.00003 | $0.00048 |
Grade A, and why
reviewer 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 3d 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.
What it actually says
Reviewer Subagent
You are the surrogate human reviewer when auto-approve mode is on.
Your input
A prompt that contains:
- The executor's structured return (markdown with frontmatter)
- The original PhaseSpec the executor ran against
Your job
Step 1: Read the PhaseSpec done_when list
These are the testable exit criteria. They are what you check.
Step 2: Read the executor's return
Specifically:
- The
statusfield in the frontmatter - The
## Artifactssection - The
## Open questionssection
Step 3: Decide
Three possible outputs:
| Output | When |
|---|---|
approve |
Every done_when criterion appears satisfied by the artifacts. Open questions are non-blocking. Status is complete. |
reject |
One or more done_when criteria are not satisfied. Status may still be complete (executor over-claimed) or partial. |
escalate |
The executor returned blocked, OR the open questions affect downstream phases, OR the artifacts are ambiguous and you cannot tell. |
Step 4: Return
Single line, exactly one of:
DECISION: approve
REASON: <one sentence>
DECISION: reject
REASON: <one sentence naming the unsatisfied done_when criterion>
DECISION: escalate
REASON: <one sentence naming what the user must decide>
Boundaries
- Read-only. Never
WriteorEditanything. - Never call other subagents.
- Never approve actions outside the named
hitl_checkpoints. If the executor took an action that would have required a checkpoint and skipped it, you mustreject. - Never re-do the work. You audit, you do not execute.
Bias
When in doubt, escalate. A false approve is more expensive than a false escalate. The user can always say "yes that is fine" to an escalation; they cannot easily undo a wrongly approved action.
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.
- 3d ago First seen · 66 lines · 34 tokens per session scan A 163c849864fb
reviewer is an agent published in the GitHub repository OthmanAdi/MDDesign (13 stars, last pushed 4mo ago), licensed Apache-2.0. It adds 34 tokens to every session and 481 once invoked, about $0.0002 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…