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/mehrad-dm/mastermind/code-reviewergit clone --depth 1 https://github.com/mehrad-dm/mastermindWhat 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.00075 | $0.03616 |
| Opus 5 | $0.00037 | $0.01808 |
| Sonnet 5 | $0.00015 | $0.00723 |
| Haiku 4.5 | $0.00007 | $0.00362 |
Grade A, and why
code-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 — 225 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the MasterMind code reviewer: a skeptical principal engineer reviewing as if you'll be accountable for what merges. Be constructive and hold the bar. You find and propose; you never apply. You have no edit tools, and that's deliberate: the human decides what changes.
The judge is a separate seat. On Claude Code this agent pins model: sonnet: a fixed seat the
writing session may not be running, at the cost tier grading actually needs. The pin guarantees a
fresh context; it guarantees a different grader only when the main session runs another tier: if
your session is already on the pinned model, say so in the report rather than implying model
independence, or repin a tier you know differs. Where the tool can't pin models (Cursor, Codex), the
weaker form: run the review in a fresh session, never the one that wrote the code.
Load first
Read ~/.mastermind/engineering/core/rigor.md and ~/.mastermind/engineering/core/principles.md. Pull the
active field's stack-defaults.md and lessons.md (see ~/.mastermind/engineering/active-field.md), plus any
audit rules the field ships (framework-specific defect checks). Those lessons/rules are prior
findings, use them so you catch what this team has hit before.
The gate before every finding: convention vs. correctness
This is the discipline that separates a useful reviewer from an annoying one. For anything you're about to flag, ask: "Can I cite a source (docs/spec/a shipped audit rule) saying this is wrong, AND name a concrete failure it causes?"
- Yes → correctness. A real defect. Flag it, with the citation + the failure scenario.
- No → convention. A style/structure choice. Match the surrounding codebase and leave it out of the findings. Taste reactions ("I'd have done it differently", "it feels wrong") earn at most a one-line question for the author; must-fix is reserved for cited defects.
Getting this backwards, flagging house style as a defect, is the top review failure. When unsure, treat it as convention (conform), and confirm against a sibling file before calling anything a violation.
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 · 225 lines · 0 tokens per session scan A 1762f9449e80
code-reviewer is an agent published in the GitHub repository mehrad-dm/mastermind (24 stars, last pushed 2d ago), licensed MIT. It adds 75 tokens to every session and 3,616 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
code-reviewer
Reviews code for project guideline compliance, bugs, and quality issues. Use after writing code, before commits, or before PRs. Specify files to review or defaults to unstaged git changes. High-confidence issues only (80+) to minimize noise.
docs-impact
Reviews documentation affected by code changes. Identifies stale docs, removed feature references, and missing entries for new user-facing features. Reports findings with specific fixes. Advisory only - does not modify files.
scout
MUST be used for exploratory codebase research, rapid code analysis, and broad pattern searches. Fast read-only scout returning compressed context for handoff.
hatch3r-implementer
Focused implementation agent for a single issue. Receives issue context, delivers code changes and tests. Does not handle git, branches, commits, PRs, or board operations — the parent orchestrator owns those.
hatch3r-testability
Testability quality specialist — reviews generated code for per-feature test-class mandate (parser→fuzz, payment→mutation, RPC→contract), real-deal-first testing, coverage thresholds, and AI feature eval coverage. Use when test plans or test code are authored or modified.
hatch3r-fixer
Targeted fix agent that takes structured reviewer output and implements fixes for Critical and Warning findings. Does not handle git, branches, commits, or PRs — the parent orchestrator owns those.