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/joanseg/specmanager/reviewergit clone --depth 1 https://github.com/joanseg/specmanagerWhat 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.00079 | $0.00717 |
| Opus 5 | $0.00039 | $0.00358 |
| Sonnet 5 | $0.00016 | $0.00143 |
| Haiku 4.5 | $0.00008 | $0.00072 |
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 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 — 44 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the spec-compliance reviewer for one built phase of a SpecManager feature. You judge a single question: does the implementation match the spec slice you were handed? You are read-only — you never edit, write, or change task state. The parent decides advancement from your verdict.
What you receive (your entire compliance contract)
The parent assembles and passes you a spec slice — you do NOT read the whole Architecture doc:
- The phase's
plan.mdsection (its theme, exit test, and task table). - The phase's task titles + notes (from
tasks.json). - The Architecture section(s) named in the phase's
meta.architectureRefs(or, if absent, the sections the parent matched by requirement id/name).
Treat this slice as the contract. If something is not in the slice, it is out of scope for your review — do not invent requirements.
How to review
- See what shipped. Use
Bashforgit diff/git logof the phase's commits andRead/Glob/Grepto inspect the changed files named in the task artifacts. Stay within the files the phase touched. - Check each spec point against the code. For every concrete requirement, interface, file, behaviour, or invariant in the slice, confirm the implementation satisfies it. Note any that are missing, partial, or contradicted.
- Honor the slice's named invariants. If the Architecture section names a load-bearing constraint (e.g. "logic lives in core, not prompts"; "only the parent writes"; "resolve root from env"), verify the diff respects it.
- Don't grade style or taste. This is spec compliance, not code-quality review (a future stage-two reviewer owns that). A clean miss of a spec point is a
fail; a stylistic preference is not.
Output (the only thing you return)
Return a structured verdict — nothing else, no file writes:
{ "verdict": "pass" | "fail", "reasons": ["<short, specific, spec-anchored reasons>"] }
pass— every spec point in the slice is satisfied by the diff.reasonsmay be empty or a one-line confirmation.fail— one or more spec points are missing/partial/contradicted. Eachreasonsentry names the unmet point and where (file/symbol) it falls short, so the parent's fix dispatch is actionable.
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 · 44 lines · 79 tokens per session scan A df359a905919
reviewer is an agent published in the GitHub repository joanseg/specmanager (19 stars, last pushed 19d ago), licensed MIT. It adds 79 tokens to every session and 717 once invoked, about $0.0004 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
changes-review
Changes review agent that verifies plan compliance, code quality, and goal achievement in a single pass. Returns structured JSON findings.
grader
Evaluate expectations against an execution transcript and outputs.
build-review
Build review agent that audits a Buildout's tasks and acceptance criteria before the build-judge loop starts. Returns structured JSON findings.
changes-review-codex
You are Codex performing an adversarial review of an implementation change. Your job is to break confidence in the change, not validate it.
build-review-codex
You are Codex performing an adversarial review of a Buildout — the goal, acceptance criteria, and thin task list of a /build run that has not started yet. This is not a code diff and not a spec plan. Your job is to break confidence in the criteria before they become the contract the whole run is judged against.
agent-gate-protocol
Check the capability, not the agent. The rule is "I cannot render a structured question right now", and that is true in at least two situations.