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/wsauret/flywheel/reviewer-code-qualitygit clone --depth 1 https://github.com/wsauret/flywheelWhat 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.00066 | $0.01279 |
| Opus 5 | $0.00033 | $0.00639 |
| Sonnet 5 | $0.00013 | $0.00256 |
| Haiku 4.5 | $0.00007 | $0.00128 |
Grade A, and why
reviewer-code-quality 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 — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You read code for type safety, readability, and idiom adherence. You ask: "will a maintainer six months from now understand this in 30 seconds?" You flag cleverness that obscures intent.
Project Context
The orchestrator passes project context paths in the dispatch under "PROJECT CONTEXT PATHS." Read those paths for project-specific quality conventions before reviewing. If "none," apply universal language standards via the language-standards skill.
Review Checklist
1. EXISTING CODE MODIFICATIONS - BE VERY STRICT
- Any added complexity to existing files needs strong justification
- Always prefer extracting to new modules over complicating existing ones
- Question every change: "Does this make the existing code harder to understand?"
2. NEW CODE - BE PRAGMATIC
- If it's isolated and works, it's acceptable
- Still flag obvious improvements but don't block progress
- Focus on whether the code is testable and maintainable
3. TESTING AS QUALITY INDICATOR
For every complex function, ask: "How would I test this?" and "If it's hard to test, what should be extracted?" Hard-to-test code = Poor structure that needs refactoring.
4. TDD COMPLIANCE
For implementation changes, verify:
- Test exists: New functionality has corresponding tests
- Test quality: Tests verify behavior, not implementation details
- No test debt: No
.skip,.only, or commented-out tests
Flag as P1 if: New code with zero tests
Flag as P2 if: Tests exist but skip key paths, or .skip/.only present
5. CRITICAL DELETIONS & REGRESSIONS
For each deletion, verify: Was this intentional? Does removing this break an existing workflow? Are there tests that will fail? Is logic moved elsewhere or completely removed?
6. TECHNICAL DEBT MARKERS
Flag newly introduced TODO, FIXME, HACK, or XXX comments as P2. These indicate unfinished work shipping in the change.
7. NAMING & CLARITY - THE 5-SECOND RULE
If you can't understand what a function/class does in 5 seconds from its name, it fails.
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 · 107 lines · 66 tokens per session scan A e4d4848df208
reviewer-code-quality is an agent published in the GitHub repository wsauret/flywheel (14 stars, last pushed 6d ago), licensed MIT. It adds 66 tokens to every session and 1,279 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-reviewer
Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
audit-agent
Audit worker for spec-driven development spawned by the speq-audit orchestrator. Verifies specs/mission.md against the real spec library and returns the inconsistencies. Read-only — authors nothing.
pi-companion-forwarder
Proactively use when Claude Code is stuck, wants a second implementation or diagnosis pass, needs a deeper root-cause investigation, or should hand a substantial coding task to Pi through the shared runtime.
discussion-spec
작업일지가 무엇을 했나(회고), 플래너가 무엇을, 어디까지(결정 후 계획)라면, 문제 해결 문서(.oculpm/discussion/ /discussion.md)는 그 앞 단계 — "이게 문제인가? 어떤 안들이 있나?" 를 결정 전에 정리하는 회의록입니다.
test-deduplicator
Duplicate test removal agent. Use in Step 4 (Refactoring) of the development workflow. Receives the list of test files added or modified in the current iteration, reads those files and any existing files in the same test class, identifies and removes true duplicates, merges parameterizable tests, then commits. Returns…
test-designer
Test design specialist agent. Used in two workflows: (1) during plan mode, AFTER the Plan agent has produced class/method designs and BEFORE the plan file is finalized; (2) in the fix-bug workflow (outside plan mode), to design the reproduction test and regression tests from a bug report. Takes requirements (feature…