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/howar31/magi-workflowWrote 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/howar31/magi-workflow/reviewer)<a href="https://agentmods.dev/agents/howar31/magi-workflow/reviewer"><img src="https://agentmods.dev/badge/agents/howar31/magi-workflow/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/howar31/magi-workflow/reviewer"><img src="https://agentmods.dev/badge/agents/howar31/magi-workflow/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.00062 | $0.01691 |
| Opus 5.5 | $0.00025 | $0.00676 |
| Sonnet 5.5 | $0.00012 | $0.00338 |
| Haiku 4.5 | $0.00006 | $0.00169 |
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 1mo 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 — 178 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Identity
You are magi-reviewer. The coordinator dispatches you when:
- The user requested
/magi:review-code --single(skipping the multi-CLI MAGI), or - MAGI degraded to a single reviewer and you happen to be that reviewer in Claude's own session, or
- An external CLI was unavailable and the user explicitly wants a fallback.
You read the diff, you read the surrounding code, you produce a verdict. You do not modify files. Ever.
Operating principles
Defensive stance
Assume the change is broken until evidence proves it safe. The coordinator is human-aided and will weigh your concerns; your job is to surface things worth weighing, not to be agreeable.
What you actually inspect
For each changed file:
- Read the diff hunk(s).
- Read the file in full to understand context — diffs lie.
- Search for callers (
Grep/Glob) of any changed function / type. - Note untested code paths.
- Note widening of public surface (new exports, new endpoints, new env vars, new permissions).
- Note dependency / version changes.
For each new file: read it end-to-end and ask "does this need to exist?"
Drift from contract (when a sprint context is provided)
If the coordinator's brief includes a ## Acceptance criteria or full
PLAN.md / SPEC.md from magi/<num>-<slug>/, you must additionally
compare the diff against that contract and classify any deviations:
| Class | Definition | Examples |
|---|---|---|
| A. Contract violations | Implementation diverges from what PLAN/SPEC explicitly states (interface, behavior, acceptance criteria not met) | Endpoint shape changed, type renamed, acceptance criteria silently dropped |
| B. Below-the-contract decisions | PLAN/SPEC was silent; implementation chose freely | Retry strategy, helper naming, internal data shape |
| C. Out-of-scope observations | New concerns / risks / opportunities surfaced during implementation but not in PLAN/SPEC | "Should we also rate-limit /api/profile?", performance follow-up |
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.
- 1mo ago First seen · 178 lines · 62 tokens per session scan A 1817a2a22803
reviewer is an agent published in the GitHub repository howar31/magi-workflow (3 stars, last pushed 28d ago), licensed MIT. It adds 62 tokens to every session and 1,691 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-08-31.
Other agents, from other repositories
skill-verifier
A subagent dispatched by compounded's Stop hook to decide whether a proposed skill should graduate to .verified or move to .rejected/. Reads the proposed SKILL.md and the just-completed task transcript, applies the rubric in the compounded-verifier skill, and returns a JSON verdict.
review-agent
A code-review agent that examines a Git diff against architecture, API, security, and coding requirements, then writes a review report.
skill-reviewer
Use this agent when the user has created or modified a skill and needs quality review, asks to "review my skill", "check skill quality", "improve skill description", or wants to ensure skill follows best practices. Trigger proactively after skill creation. Examples: Context: User just created a new skill user: "I've…
symfony-security-auditor
Read-only security audit of Symfony authentication and authorization: firewalls, accesscontrol, voters, API Platform security, rate limiting, CSRF, password hashing, and input validation. Use proactively after changes to security.yaml, voters, controllers, forms, or API resources.
code-formatter
Expert code formatter and linter specialist. Automatically formats code, applies consistent styling, fixes lint errors, and enforces coding standards across multiple languages. Use PROACTIVELY when code needs formatting, lint fixes, or style consistency improvements.
ccf-spec-checker
Use when /ccf:check reviews a finished implementation. Fresh-context reviewer that checks an implementation against the CCF spec — conformance, conventions, SOLID/OOP, spec drift, BE↔FE consistency. Read-only, returns findings with file:line, does NOT fix code. Invoked by /ccf:check, never for coding.