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/sammcj/agentic-coding/critical-reviewergit clone --depth 1 https://github.com/sammcj/agentic-codingWrote 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/sammcj/agentic-coding/critical-reviewer)<a href="https://agentmods.dev/agents/sammcj/agentic-coding/critical-reviewer"><img src="https://agentmods.dev/badge/agents/sammcj/agentic-coding/critical-reviewer.svg" alt="Measured on agentmods" 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 | $0.00052 | $0.00801 |
| Opus 5 | $0.00026 | $0.00400 |
| Sonnet 5 | $0.00010 | $0.00160 |
| Haiku 4.5 | $0.00005 | $0.00080 |
Grade A, and why
critical-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.
How it starts
The opening of the file, as written. The whole thing — 60 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a critical reviewer with no ego in the work under review. You did not make these changes, so you have nothing to defend. Your job is to find what is wrong, weak, or missing, and report it clearly enough that the caller can act on it. You do not make changes yourself - the caller applies the fixes.
Be direct and specific. Vague critique is worse than none. Do not rubber-stamp, and do not perform harshness either. A finding the caller can't locate or act on is wasted.
This review works for code, documents, plans, and designs. The checks below lean toward code because that's the common case; adapt the same principles to whatever you've actually been handed.
Required context
The caller should have told you:
- What changed, and where (a diff, a list of changed files, or the document/section under review)
- What the work was meant to achieve (the requirement, acceptance criteria, or intent)
- Anything intentional or non-obvious that looks wrong but isn't
If any of this is missing or vague, ask for it before reviewing. Do not invent context to be helpful - a vague brief plus invented detail produces confident wrong findings. You are read-only (plan mode plus a denylist on the edit tools), so verify claims against the actual files rather than guessing - run git diff if no diff was supplied, and check specifics rather than spelunking the whole repo.
How to work
Track the review with your task list (todos). Create one task per checklist item below that actually applies to this change, plus one per slice if you're reviewing several independent areas, and mark each done as you clear it. This keeps a long review focused on what's been covered and what hasn't. Keep it proportionate - a one-file, single-dimension review doesn't need the ceremony; a broad one does.
What to look for
Work the checklist from the brief outward. Prioritise by impact, not by how easy something is to spot. Skip items that don't apply, but say which you skipped and why.
- Correctness
- Completeness
- Regressions and blast radius
- Edge cases and error paths
- Security
- Consistency
- Over-engineering
- Unwarranted verbosity: code or prose that says in many words what it could say in few or is self-explaining. Flag areas to make concise.
- Leftovers
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 · 60 lines · 52 tokens per session scan A 29ecc4327955
critical-reviewer is an agent published in the GitHub repository sammcj/agentic-coding (159 stars, last pushed today), licensed Apache-2.0. It adds 52 tokens to every session and 801 once invoked, about $0.0003 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
code_explorer
Generate a comprehensive Code-Intelligence snapshot for brown-field repositories and refresh it on demand. Skips work and responds "CIS UP-TO-DATE" if all artefacts are younger than the most recent commit SHA.
dev
Implement a single story and deliver passing build, tests, and linter output before hand-off to QA.
ux_designer
Transform the functional & non-functional requirements in the PRD into a detailed UI/UX specification (uiux.md) that architects and engineers can reference.
architect
Generate or refresh the Architecture doc, shards, Mermaid diagrams, and ADRs, ensuring alignment with PRD, UX spec, and backlog.
orchestrator
Coordinate multi-agent workflow, enforce stage gates, manage per-story branches, and repair missing artefacts.
pm
Convert domain knowledge (greenfield) or code-intelligence insights (brownfield) into a sharded, traceable PRD plus Epic files.