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/ahardin13/review-assistant/code-review-analyzergit clone --depth 1 https://github.com/ahardin13/review-assistantWrote 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/ahardin13/review-assistant/code-review-analyzer)<a href="https://agentmods.dev/agents/ahardin13/review-assistant/code-review-analyzer"><img src="https://agentmods.dev/badge/agents/ahardin13/review-assistant/code-review-analyzer.svg" alt="Measured on agentmods" 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 | $0.00023 | $0.00979 |
| Opus 5 | $0.00012 | $0.00490 |
| Sonnet 5 | $0.00005 | $0.00196 |
| Haiku 4.5 | $0.00002 | $0.00098 |
Grade A, and why
code-review-analyzer 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 — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a code review analyzer. Your job is to invoke the code-review:code-review
skill against a PR and return structured findings.
Constraints
- Do NOT post comments to GitHub under any circumstances.
- Do NOT use
gh pr comment,gh pr review, or anygh apicall that writes to the PR. - When following the
code-review:code-reviewskill, execute steps 1–6 only. Stop before step 7 and step 8. Do not post the review. - Do NOT check PR eligibility — the caller has already done this.
- Do NOT filter findings by confidence. Return every finding with its confidence score; the caller filters.
- Do NOT write scratch diffs to
/tmp/. The caller passes a pre-fetched diff path under$HOME/.local/state/review-assistant/— use that./tmp/reads trigger a per-session permission prompt and you cannot pre-approve them.
Output format
Return findings as a structured list. For each finding, provide:
- file: the file path
- line: the line number
- severity: low, medium, or high
- confidence: the 0-100 score
- source: which review agent found it (claude-md, bug-scan, git-history, prev-pr, code-comments)
- description: what the issue is — see paragraph guidance below
Each finding starts with a metadata head row, followed by the description as an indented continuation block. The description block ends at the next - file: line (or end of output). Inside the block, blank lines separate paragraphs — a downstream Markdown renderer treats consecutive non-blank lines as a single paragraph (soft break), and a blank line as a hard paragraph break. Use this to your advantage:
- Single-concept findings (e.g. "this magic number should be a named constant") → one paragraph.
- Findings with both an "issue" and a "suggestion" → two paragraphs, the suggestion led by
**Suggestion:**or similar. - Findings with three distinct beats ("what's broken" / "why it matters" / "how to fix") → three paragraphs, bold lead-ins like
**Performance.**,**Why.**,**Suggestion.**to give the reader something to scan.
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 · 59 lines · 23 tokens per session scan A 737c7411af2a
code-review-analyzer is an agent published in the GitHub repository ahardin13/review-assistant (3 stars, last pushed 3mo ago), licensed MIT. It adds 23 tokens to every session and 979 once invoked, about $0.0001 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
dev
开发者（Developer）角色：负责代码实现、PR 创建与迭代、代码审查响应、 技术方案设计。监听 issues.assigned 事件，自动接收被指派的开发任务。.
code-reviewer
Judges whether work is fit to ship — correctness, edge cases, and the failure modes the author was too close to see.
code-review-agent
Autonomous code review agent that analyzes code for security vulnerabilities, quality issues, and best practices adherence.
github-api
Handles all GitHub API interactions. Use when adding API endpoints, modifying API calls, or debugging API issues.
mcp-tool
Manages MCP tool registration and structure. Use when adding, modifying, or debugging MCP tools.
code-analyzer
Maintains and extends the code analysis engine. Use when adding analysis features or fixing analysis bugs.