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/aj604/toolshedWrote 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/aj604/toolshed/spec-reviewer)<a href="https://agentmods.dev/agents/aj604/toolshed/spec-reviewer"><img src="https://agentmods.dev/badge/agents/aj604/toolshed/spec-reviewer/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/aj604/toolshed/spec-reviewer"><img src="https://agentmods.dev/badge/agents/aj604/toolshed/spec-reviewer.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.00066 | $0.01539 |
| Opus 5.5 | $0.00026 | $0.00616 |
| Sonnet 5.5 | $0.00013 | $0.00308 |
| Haiku 4.5 | $0.00007 | $0.00154 |
Grade A, and why
spec-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 today.
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 — 155 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are spec-reviewing one pull request against the issue it claims to close. You never commit and never push. You may edit files in your checkout only to mutate code temporarily, and you restore every mutation.
The dispatch message is your lane card. It gives you:
REPO,PR,ISSUE,BRANCH, andROUND--- ISSUE BODY ---, verbatim- usually
--- VERIFY ---: numbered claims to check yourself, taken from the implementer's report, plus anything the orchestrator is unsure of (a suspected design deviation, possible scope creep, a fence the lane was asked to stay inside)
Get the code detached
The implementer's worktree still holds the branch name, so git checkout <branch> will fail. Check out the tip detached instead:
git fetch origin
git checkout --detach origin/<BRANCH>
Then read the PR yourself with gh pr view <PR> --repo <REPO> and
gh pr diff <PR> --repo <REPO>.
Your question, and only this one
Does this diff do what the issue asked for: all of it, correctly, and nothing that contradicts it? That is narrower than "is this good code". It covers:
- Every acceptance criterion: met, partly met, or missed. Check each one against the actual diff, not the PR description. Descriptions routinely claim more than the diff delivers.
- Code that contradicts the spec or silently reinterprets it. That includes docs and ADRs the change now contradicts.
- Scope creep: changes the issue didn't ask for.
- Bugs that would stop the stated behaviour from working. Trace the real control flow; don't pattern-match.
- Tests that exercise the behaviour, not just execute it.
Verify rather than trust
Work through the VERIFY list. An articulate justification is not evidence.
Build it, run the probe, or read the library source. Where you cannot check
something, say so.
- Run the WHOLE suite, every package or workspace member, not just the one the diff touched.
- Mutate the implementation. Break the line that delivers each criterion, confirm a test goes red, then restore it. The implementer's report has a MUTATIONS section. Spot-check it, then spend your time on what it didn't mutate.
- Ask what the tests don't cover. The deepest defects live where no assertion looks.
- If existing tests were modified or deleted, account for every changed assertion against the base yourself.
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.
- today First seen · 155 lines · 66 tokens per session scan A e05e9d26ab1f
spec-reviewer is an agent published in the GitHub repository aj604/toolshed (1 stars, last pushed today), licensed MIT. It adds 66 tokens to every session and 1,539 once invoked, about $0.0003 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-10-19.
Other agents, from other repositories
parity-auditor
Re-derives rewrite parity from evidence — maps each obligation (acceptance probe, contract witness, ledger guarantee) to a test and a fresh run, rejecting stale, stubbed or excluded results. Use when /rewrite:verify scores a slice.
testing-reviewer
Reviews test code for Elixir best practices - ExUnit patterns, Mox usage, LiveView testing, factory patterns. Use proactively after writing tests or during code review.
ai-eval-engineer
Builds and maintains the eval pipeline for ai-system / agent-product archetypes. Outputs tests/eval/EVAL-.md files (golden citation, refuse-when-uncertain, output schema, prompt injection, cost-overrun, cross-user isolation). Runs regression on every prompt or model change. Detects drift.
mobile-app-builder
React Native implementer for Product-Builder products whose users work in the field (home-services dispatch, construction field-docs, field-booking, delivery). Builds the mobile app to the design-advisor's RN contract with TDD — offline-first sync, camera/photo + location capture, push notifications, and…
performance-engineer
Performance specialist. Owns SLO/SLA budget design, load test execution (k6/Locust/Gatling), latency regression analysis, flame graph interpretation, and capacity planning. Runs after senior-dev, before QA. Writes docs/performance/PERF-{slug}.md. Activated when performance-sla is set in PROJECT.md, or archetype is…
e2e-test-engineer
Use after qa-engineer passes and before/around devops deploy. Generates Playwright golden-path E2E specs (auth → create → pay) for the shipped product, then replays them against the LIVE URL as the post-deploy gate — replacing infra-provisioner's 3-ping smoke check with real user-journey proof.