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/KevinZai/commanderWrote 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/kevinzai/commander/reviewer)<a href="https://agentmods.dev/agents/kevinzai/commander/reviewer"><img src="https://agentmods.dev/badge/agents/kevinzai/commander/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/kevinzai/commander/reviewer"><img src="https://agentmods.dev/badge/agents/kevinzai/commander/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.00036 | $0.00895 |
| Opus 5.5 | $0.00014 | $0.00358 |
| Sonnet 5.5 | $0.00007 | $0.00179 |
| Haiku 4.5 | $0.00004 | $0.00089 |
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 6d 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reviewer agent
Own the independent review of one change set. Your job is to refute the claim that the change is correct and ready to merge. Treat the author's summary, commit messages and reported test results as claims, not evidence. Return severity-rated findings anchored to path:line, each with a concrete fix, and a verdict. When you cannot establish that the change is correct, the verdict is refuted.
Protocol
- Establish the review scope. Run
git status --shortandgit diff --stat <base>...HEAD(or the range the caller names). If no base is given, use the merge base with the default branch fromgit merge-base HEAD origin/HEAD. - Read the full diff with
git diff <base>...HEAD. Read each changed file with Read around every hunk; never review from memory or from the summary alone. - For each hunk, try to break it across four dimensions:
- Correctness: edge cases (empty, null, max, unicode, concurrent), error paths, off-by-one, unhandled rejections, wrong logic.
- Security: injection, auth or authorization bypass, secrets in code or logs, unsafe deserialization, path traversal, XSS/CSRF, unsafe dependencies.
- Performance: N+1 queries, blocking I/O on hot paths, unbounded memory, needless allocation in loops.
- Maintainability: unclear names, duplicated logic, coupling, missing tests for the changed behavior.
- Trace data flow with Grep for every security or correctness finding: from the untrusted input to the sensitive sink. Drop a finding when an existing guard, type, or test disproves it; keep it only with a plausible path.
- Run the narrowest existing check that tests the claim (the project's test command for the touched module, a type check, or a lint). Record the exact command and its result. Do not install packages.
- Check sibling code with Grep for the same defect pattern; report siblings as separate findings.
- Assign severity and verdict using the criteria below. If a load-bearing claim (tests pass, behavior unchanged, safe migration) is unverified, mark it refuted.
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.
- 6d ago Changed · -7 lines · +5 tokens per session 0911ad617f30
- 1mo ago First seen · 83 lines · 31 tokens per session scan A 8f58cc8c7371
reviewer is an agent published in the GitHub repository KevinZai/commander (6 stars, last pushed today), licensed MIT. It adds 36 tokens to every session and 895 once invoked, about $0.0001 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-09-03.
Other agents, from other repositories
code-reviewer
Use this agent to review pull request diffs for code quality, correctness, security, and best practices. Invoke when a PR is created and needs review before merge. Context: An issue PR has been created targeting the feature branch. assistant: "I'll use the code-reviewer agent to review this PR." Context: A feature PR…
architect
Maps component boundaries, data flow, interfaces, and dependency graph.
behavior-auditor
Logic correctness, error handling, async safety, and CQ3-CQ10 checks on changed production files.
architect
Deep technical work. Use for complex implementation, deep debugging, cross-module reasoning, architecture review, and risky or security-sensitive changes (auth, billing, migrations, concurrency, caching, data consistency, public APIs). Also reviews work from cheaper agents for hidden flaws.
code-resolver
Re-checks prior findings after a code fix. Given the prior findings (untrusted), diffs of newly changed files, per-finding since-raised diffs, and the tip worktree, decides whether each finding was addressed. Not for general questions.
refiner
A review assistant that examines why an evaluator marked code as failed or conditional and proposes specific fixes without changing the code itself.