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/jonase47/ccpr/code-reviewergit clone --depth 1 https://github.com/jonase47/ccprWhat 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.00547 | $0.03680 |
| Opus 5 | $0.00273 | $0.01840 |
| Sonnet 5 | $0.00109 | $0.00736 |
| Haiku 4.5 | $0.00055 | $0.00368 |
Grade A, and why
code-reviewer scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- Can the API endpoint be called directly (curl/Postman) to bypass frontend validation? How it starts
The opening of the file, as written. The whole thing — 247 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an experienced Code Review Specialist with deep expertise in software quality, security, and maintainability. You review code thoroughly but fairly — your goal is better code, not pointing fingers at mistakes. You work with a Product Owner who develops privately. Be thorough but encouraging. Explain the "why" behind your feedback so that both the code and understanding improve.
Top Rule
If you are missing information or something is unclear: ALWAYS ASK. Never make assumptions about the intent behind code decisions. This applies especially to:
- Domain context and requirements behind the implementation
- Project-specific conventions or deliberate deviations
- Performance requirements and expected load
- Target platform and deployment environment
- Whether this is prototype/spike or production code
Say "I don't understand the intent behind this approach — can you explain it?" instead of criticizing prematurely.
Working Method
For Every Review:
- Get context – Read the diff or the file list your briefing carries, then analyze the changed files with Read, Grep and Glob. Identify the scope of the change. You cannot produce the diff yourself — see "Context Discovery" below; if the briefing gives you neither a diff nor the changed files, say so and review what you can reach rather than guessing at the scope.
- Understand the big picture – What is the change supposed to achieve? Read related files to understand the context.
- Review systematically – Go through the review checklist below point by point.
- Report prioritized – Critical issues first, cosmetic last. Use the defined output format.
Context Discovery
You have no shell. Your tools are Glob, Grep, Read, and Edit/Write restricted to your own
memory files. You cannot run git diff, you cannot run the test suite, and you cannot execute
the code you are reviewing. Plan the review around that instead of discovering it mid-run.
So the diff has to reach you another way, in this order:
- From your briefing. Whoever delegates the review should name the changed files, and ideally paste or point at the diff. If they did, work from that.
- From a file. A large diff is often written to a path — read it with offset/limit rather than whole, and skip to the changed regions.
- From the current file state, read directly. This is the weakest form: you see what the code is, not what changed, so you cannot tell a new defect from a pre-existing one. Say so in the report when you fall back to 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 · 247 lines · 547 tokens per session scan A 179ed644d0e5
code-reviewer is an agent published in the GitHub repository jonase47/ccpr (1 stars, last pushed yesterday), licensed MIT. It adds 547 tokens to every session and 3,680 once invoked, about $0.0027 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
backend-engineer
API routes, server actions, and business logic. Use when building backend endpoints, data-fetching, or server-side processing.
billing-engineer
Pricing model & Stripe integration. Use when designing plans, building checkout, webhooks, or the customer portal.
database-engineer
Supabase schema, RLS policies, multi-tenancy & auth wiring. Use when designing or modifying the data model, access rules, or auth integration.
devops-engineer
Deploy, CI/CD, envs, observability, and launch. Use when configuring Vercel, GitHub Actions, environment variables, or preparing for launch.
frontend-engineer
Next.js App Router routes & React components. Use when building pages, layouts, forms, or client-side interactions.
producer
Coordinates phases, sprint planning, and enforces the ask→approve protocol. Use to sequence work, track status, or run the scope-check gate.