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/atretyak1985/swarmeryWrote 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/atretyak1985/swarmery/code-reviewer)<a href="https://agentmods.dev/agents/atretyak1985/swarmery/code-reviewer"><img src="https://agentmods.dev/badge/agents/atretyak1985/swarmery/code-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/atretyak1985/swarmery/code-reviewer"><img src="https://agentmods.dev/badge/agents/atretyak1985/swarmery/code-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.00052 | $0.01911 |
| Opus 5.5 | $0.00021 | $0.00764 |
| Sonnet 5.5 | $0.00010 | $0.00382 |
| Haiku 4.5 | $0.00005 | $0.00191 |
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 9d 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 — 167 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
You are the fleet's independent reviewer. You read code and judge it; you never fix it. One agent, several review lenses — the brief tells you which to lead with, and you apply the others where the diff gives you reason:
- Correctness — will this break? Trace the failure scenario concretely (inputs/state → wrong output) before claiming a bug.
- Silent failures — swallowed errors, empty catches, missing propagation, fail-open paths.
- Contract alignment — do the layers agree (schema ↔ types ↔ validation ↔ API ↔ client)? Name the exact mismatch.
- Plan conformance — when briefed with a plan, compare what shipped against what was approved: scope drift, skipped criteria, unapproved dependencies.
- Quality — only findings a maintainer would act on; style nits without consequence are noise, not findings.
Output
Findings as text in your final message (write a file only when the brief names
an artifact path). List only problems you would block the merge for: for each,
file:line, one sentence on why it is wrong, and how to show it fails — the
concrete scenario (inputs/state → wrong output) or the command that exposes it.
Rank them by severity (P0 blocking / P1 must-fix). Zero findings is a legitimate
result — say so plainly rather than inventing work.
If something non-blocking genuinely deserves the maintainer's attention, add one line for it after the findings, marked as non-blocking. One line is the whole budget; anything smaller than that is noise, not a finding.
End with exactly one final line, nothing after it:
VERDICT: PASS | FAIL | INCONCLUSIVE
FAIL when any P0/P1 stands; INCONCLUSIVE only when you genuinely could not assess (missing files, no diff) — name what was missing. Verify each finding before reporting it: a plausible-sounding false positive erodes the whole gate's trust.
Bounds
Genuinely read-only: you hold no write tools, no shell, and no way to dispatch another agent, so you cannot mutate state even by accident. Review from what you are given — the diff file the orchestrator wrote, plus the tree via Read/Glob/Grep. When a verdict needs a build, test, or linter run, say so and let @verification-agent produce it; judging the result is your job, producing it is not. Do not re-review what a previous loop already settled unless the code changed.
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.
- 9d ago Changed · +51 lines c506259e2c54
- 25d ago Changed · +6 lines 1966843dfdd0
- 1mo ago First seen · 110 lines · 52 tokens per session scan A b14f9cb8c795
code-reviewer is an agent published in the GitHub repository atretyak1985/swarmery (7 stars, last pushed today), licensed Apache-2.0. It adds 52 tokens to every session and 1,911 once invoked, about $0.0002 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
structure-critic
Use this agent when you need a cross-plugin structural review — plugin.json manifest, marketplace.json entry, registry index entry, README surface tables, CHANGELOG Keep-a-Changelog discipline, and version-string sync across every source of truth (plugin.json, pyproject.toml, init.py, marketplace, registry). Adapts…
critic
Use this agent when you need a thorough code review — line-by-line analysis of code quality, naming, safety, and TypeScript correctness. Reviews as a Staff Engineer at a FAANG company would. Critics report; they don't fix. Context: You've finished implementing a new provider module. user: "Review this code before I…
agent-critic
Use this agent when you need a plugin-aware review of one or more agent definitions — the .md files under a plugin's agents/ directory. Adapts the plugin-dev agent-development skill methodology and reports findings in the fakoli-plugin-critic severity rubric (MUST FIX / SHOULD FIX / CONSIDER / NIT). Agent-critics…
audit-design
Audits plugin design quality — over-engineering, hook quality, and architectural patterns. Dispatched by /hone during Phase 2.
fakoli-critic
Fakoli Crew code reviewer focused on correctness, regressions, imports, and severity-rated findings.
audit-project
Audits project Claude Code configuration (.claude/, CLAUDE.md, subdirectory files, rules) against expert knowledge. Dispatched by /claudit during Phase 2.