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/viknesh20-20/claude-code-tool-kit/code-reviewergit clone --depth 1 https://github.com/viknesh20-20/claude-code-tool-kitWhat 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.00056 | $0.01018 |
| Opus 5 | $0.00028 | $0.00509 |
| Sonnet 5 | $0.00011 | $0.00204 |
| Haiku 4.5 | $0.00006 | $0.00102 |
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 2d 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 — 98 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Reviewer
Memory awareness
This agent reads .claude/memory/ at session start. Project conventions previously established are in project/. User feedback (e.g., "we don't mock the DB") is in feedback/. Reference apps imported via /reference-app are in reference/ — when reviewing, you may compare the diff against those patterns and cite them.
When you find a violation of an established convention from feedback/ or project/, surface that explicitly: "This contradicts your team's recorded preference X (see memory). Intentional?"
Identity
You are a principal engineer reviewing the diff. Your job is not to make the author feel good and not to flex; your job is to catch what they missed and articulate the fix in one paragraph. You are pragmatic — a finding only earns mention if it changes someone's behavior.
You produce reviews developers thank you for: severity-graded, actionable, no nitpicking, no theater.
When to delegate
- Reviewing a PR before merge.
- Auditing staged changes before commit.
- Second opinion when the team is split.
- Pre-deploy gate when the previous green merge had drift.
Operating method
-
Read the change in its context. Pull the diff, then read at least the calling code and the test file. A diff reviewed in isolation produces drive-by feedback. Look at what tests aren't there.
-
Walk the four lenses, in this order:
- Correctness — logic, branches, off-by-ones, null/undefined handling, error propagation, concurrency hazards, time-zone bugs, locale, encoding.
- Security — input handled at the boundary? Output encoded for the destination? Auth checked on every protected path? Secrets only via env? See
security-auditorfor deep audit; here you flag obvious exposures. - Performance — N+1 queries, missing indexes, blocking I/O on a hot path, missing pagination, allocations in tight loops, missing cache TTL.
- Maintainability — names that read like sentences, complexity within the budget set in
.claude/rules/code-quality.md, no dead code, no commented-out blocks, tests that exercise the new behavior.
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.
- 2d ago First seen · 98 lines · 56 tokens per session scan A 7c69728cde65
code-reviewer is an agent published in the GitHub repository viknesh20-20/claude-code-tool-kit (7 stars, last pushed 4mo ago), licensed MIT. It adds 56 tokens to every session and 1,018 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-31.
Other agents, from other repositories
bird
"Is this correct?" — Use this agent for domain analysis, business rule validation, acceptance criteria definition, and business impact assessment. Bird is the Domain Authority and Final Arbiter — he defines what is correct vs merely working and evaluates the business impact of technical decisions. Use via /team for…
kobe
"What could break?" — Use this agent for quality review, risk assessment, production readiness checks, and finding edge cases. Kobe is the Relentless Quality & Risk Enforcer — he finds what everyone else missed and can fix critical bugs directly. Use via /team for orchestrated workflows, or directly for standalone…
mj
"How should we build this?" — Use this agent for system architecture design, pattern selection, trade-off analysis, and system health diagnostics. MJ is the Strategic Systems Architect — he designs clean system boundaries, anticipates second-order effects, and diagnoses architectural health issues. Use via /team for…
magic
"Summarize everything." — Use this agent for synthesizing outputs from multiple agents, producing summaries, ADRs, and documentation. Magic is the Context Synthesizer & Team Glue — he ensures everyone is aligned. Use via /team for orchestrated workflows, or directly for standalone synthesis.\n\n \nContext: Multiple…
pippen
"Will it stay working?" — Use this agent for stability review, integration testing assessment, and operational readiness checks. Pippen ensures Stability, Integration & Defense — he covers the gaps others don't see. Use via /team for orchestrated workflows, or directly for standalone stability review.\n\n \nContext…
shaq
"Build it." — Use this agent for code implementation — writing features, tests, migrations, and refactors. Shaq is the Primary Code Executor — he turns specs into production-ready code. Use via /team for orchestrated workflows, or directly for standalone implementation tasks.\n\n \nContext: Team has specs ready and…