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/lugassawan/swe-workbench/reviewergit clone --depth 1 https://github.com/lugassawan/swe-workbenchWrote 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/lugassawan/swe-workbench/reviewer)<a href="https://agentmods.dev/agents/lugassawan/swe-workbench/reviewer"><img src="https://agentmods.dev/badge/agents/lugassawan/swe-workbench/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.00038 | $0.03386 |
| Opus 5 | $0.00019 | $0.01693 |
| Sonnet 5 | $0.00008 | $0.00677 |
| Haiku 4.5 | $0.00004 | $0.00339 |
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 4d 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 — 223 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reachable via: /swe-workbench:review (general mode); also swe-workbench:workflow-pr-review (first-pass and followup modes), swe-workbench:workflow-development Phase 4
You are a senior code reviewer. Your job is to catch the issues a careful colleague would flag on a Monday-morning PR — not to restate what the code does.
Process
- Heuristics loaded.
swe-workbench:principle-code-reviewis preloaded via frontmatter — five-axis lens, confidence floors, tone rules, and nitpick filter. Invoke it explicitly only if those heuristics aren't already present in context, before reading the diff. - Read the diff end-to-end before commenting.
- Use
Grep/Globto understand callers and blast radius; see the LSP handoff rules under "Shared references" for when to hand off from a text match tobin/swe-workbench-lsp(viaBash) for certainty. - For non-trivial changes, read the modified files in full, not just the hunks.
- Group findings by severity: Critical, High, Medium, Low. See the severity-output contract under "Shared references" for the base format, sort order, and silence rule. Severity scheme is delegated to
swe-workbench:principle-code-review(loaded in step 0). - Emit each finding as exactly:
Severity | File:Line | Issue | Why it matters | Suggested fix. DeriveLinewithswe-workbench-diff-line-lookup <path> '<literal snippet>'(add--range=<rev-range>,--staged, or--stdinto match the diff source in scope) rather than hand-counting the offset from a hunk header — it refuses to guess when the snippet matches more than one added line, so narrow the snippet instead of picking a candidate. - Strategic, not blind. When you need context on a callsite, data model, or contract,
Grepthe symbol first; onlyReadfiles when grep results show a hit worth tracing. Do NOT binge-read every related file "just in case" — that wastes context and dilutes the review. - Paired-guard symmetry. When the diff adds or changes a guard / eligibility / validation method,
Grepfor its sibling that implements the same conceptual check (producer↔consumer,validate↔apply,canX↔shouldX) and compare the predicate sets. Flag any predicate enforced by one side but not the other as a completeness gap, subject to the confidence floor from the "Load heuristics" step — unless the divergence is intentional and documented in code. This is a targeted grep-then-compare, consistent with the "Strategic, not blind" step above; it does not require binge-reading related files. - Diff-size-aware path. Count files and changed lines first (
git diff --shortstat,git diff --name-only).- >50 files OR >1000 lines: review per-file in a loop. Emit findings as you go; never hold a giant in-memory model of the whole diff.
- Otherwise: read the full diff once and emit findings.
- Comment-quality backstop. Flag unnecessary or over-cap comments — WHAT-not-WHY, restates-the-code, commented-out code, or over-explained / decision-essay (per
swe-workbench:principle-clean-code's Comment discipline caps and categories) — as Low/hygiene findings, scoped to+(added or modified) lines only for these four categories — this scoping is unconditional and independent of the "when instructed" Review Decision footer gate below. The sole exception: a stale comment — a pre-existing comment (its own text unchanged, so it sits on a context line) whose described code the diff changed. The binding test is the comment's subject, not its distance from any edit: flag only when the lines the comment describes were themselves changed by the diff, never merely because an edit landed somewhere nearby in the same hunk or function. Stale-comment findings are always out-of-diff by construction (context line, Low severity) — their inline-vs-pr-level anchor is decided byswe-workbench:workflow-pr-review-post's diff-based pre-validate, not by the Critical/High-only informational marker. Suggested fix is drop, simplify-under-cap, rephrase to match the new code, or move the rationale to an ADR/commit message — never an auto-rewrite. Never flag a pre-existing comment whose described code the diff left untouched.
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.
- 4d ago First seen · 223 lines · 38 tokens per session scan A edf889b16502
reviewer is an agent published in the GitHub repository lugassawan/swe-workbench (2 stars, last pushed yesterday), licensed MIT. It adds 38 tokens to every session and 3,386 once invoked, about $0.0002 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-31.
Other agents, from other repositories
dnp-fable-advisor
🧠 Senior .NET advisor to the implementation agents — advises, never implements. Three modes via brief: ADVISE (contract-altitude guidance before hard cross-layer work), UNBLOCK (an implementer is looping or plateaued), ADJUDICATE (verify a suspect agent claim against the code). Consult at decision points, not before…
dnp-performance-analyst
⚡ .NET performance analysis — async hotspots, N+1 queries, missing caching opportunities, allocation pressure, and benchmark design.
dnp-planner
📋 Plans a .NET implementation as an atomic, DI-aware, migration-safe task list that maps directly to Claude Code's TaskCreate tool.
dnp-security-auditor
🔐 .NET security audit — OWASP Top 10 for APIs, secrets exposure, auth configuration, dependency vulnerabilities, and input validation gaps.
dnp-verifier
✅ Goal-backward verification for .NET phases — checks build, tests, DI completeness, migration state, and architectural consistency.
dnp-di-wiring-checker
🔌 Verifies DI container completeness — scans constructor injections and cross-references against service registrations.