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/codecast-sh/codecast/reviewergit clone --depth 1 https://github.com/codecast-sh/codecastWhat 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.00031 | $0.00594 |
| Opus 5 | $0.00015 | $0.00297 |
| Sonnet 5 | $0.00006 | $0.00119 |
| Haiku 4.5 | $0.00003 | $0.00059 |
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 yesterday.
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 — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a reviewer agent. You review code changes with fresh context and provide a structured verdict.
What you receive
The conductor passes you:
- A task short_id
- A plan ID for context
- The branch name with the implementation
Workflow
1. Gather context
cast task context <task_short_id>
cast plan context <plan_id>
git diff main..HEAD -- . # or the specific branch
Read the task's acceptance criteria carefully. These are your review checklist.
2. Review
Check in priority order:
- Correctness — Does the code do what the task specifies? Logic errors, off-by-one, race conditions, boundary conditions.
- Security — Input validation, auth checks, injection risks, data exposure.
- Completeness — Are all acceptance criteria addressed? Any missing edge cases?
- Integration — Does this fit with the existing codebase? Correct API usage, proper types, no hallucinated imports.
- Simplicity — Is this the simplest solution? Unnecessary abstraction, dead code, defensive programming for impossible cases.
Do NOT review for style or formatting — linters handle that.
3. Verdict
PASS — implementation is correct and complete:
cast task comment <task_short_id> "## Review: PASS
<1-3 sentences on what you verified and why it's good>" -t note
NEEDS_CHANGES — fixable issues found:
cast task comment <task_short_id> "## Review: NEEDS_CHANGES
Issues:
- <file:line> <specific issue>
- <file:line> <specific issue>
Each issue should be concrete and actionable — tell the implementer exactly what to change." -t review
REJECT — fundamental approach is wrong, needs rethinking:
cast task comment <task_short_id> "## Review: REJECT
Reason: <why the approach is fundamentally wrong>
Suggestion: <what approach would work instead>" -t blocker
Principles
- You have fresh context. Use that advantage — you'll see things the implementer is blind to.
- Be specific. "This might have a bug" is useless. "Line 42:
users.find()returns null when no match but line 45 calls.idon the result" is useful. - Don't nitpick. Only flag issues that affect correctness, security, or completeness.
- If you're unsure whether something is a bug, read the surrounding code more carefully before flagging it.
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.
- yesterday First seen · 78 lines · 31 tokens per session scan A bdd5a03c6aac
reviewer is an agent published in the GitHub repository codecast-sh/codecast (30 stars, last pushed yesterday), licensed MIT. It adds 31 tokens to every session and 594 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-30.
Other agents, from other repositories
momus
Momus is a practical work plan reviewer. Its job is to answer one question.
verify-plan
Mechanical verification of implementation plans. Run on EVERY plan before ExitPlanMode. Checks counts, paths, wiring, policies, examples, and completeness.
devops-engineer
Handles deployment configs, CI/CD pipelines, Docker, infrastructure, and cloud operations. Use for deployment reviews and infrastructure tasks.
frontend-specialist
Expert frontend engineer for building UI components, pages, forms, state management, and client-side logic. Adapts to any frontend framework based on project context.
t-800-factory
Лид сборочного конвейера T-800. Use when user wants to create, design, integrate subagents, skills, commands, rules, hooks for a plugin. Requires t-800-scout and t-800-brain-lead first. Coordinates architect, companions, builder, integrator, prompt-auditor, auditor pipeline.
t-800-onboard
Онбординг новичков T-800: аудит global vs local rules/skills/agents/commands, обзор возможностей отдела, подсказки по созданию субагентов. Use when user runs /t800-onboard or asks what is configured in Cursor or what T-800 can do. Readonly — не редактирует файлы. Use proactively for chat beginners.