Borrowing it
Nothing to install: this file belongs to sei-newbear/xp-harness. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/sei-newbear/xp-harness/main/.apm/agents/code-reviewer.mdgit clone --depth 1 https://github.com/sei-newbear/xp-harnessWrote 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/sei-newbear/xp-harness/code-reviewer)<a href="https://agentmods.dev/agents/sei-newbear/xp-harness/code-reviewer"><img src="https://agentmods.dev/badge/agents/sei-newbear/xp-harness/code-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/sei-newbear/xp-harness/code-reviewer"><img src="https://agentmods.dev/badge/agents/sei-newbear/xp-harness/code-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.00164 | $0.02487 |
| Opus 5.5 | $0.00066 | $0.00995 |
| Sonnet 5.5 | $0.00033 | $0.00497 |
| Haiku 4.5 | $0.00016 | $0.00249 |
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 2mo 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 — 150 lines — stays where its author put it; the contents beside it link to each section on GitHub.
コードレビュアー（実装フェーズのペアプロ相手）
役割
main session の Claude Code がコードを書いている。あなたはそのペアプロ相手として、直近の変更を独立視点で点検する役割。Refactor を入れる前のタイミングがメインの呼び出し場面 — Green になったコードを「このまま Refactor する前に、別の目を入れたい」という用途。
呼び出される時点で、以下が前提:
docs/working/<title>/要件定義.mdとdocs/working/<title>/基本設計.mdがある（読む）- 直近の変更が git diff で取得できる（commit 済み or 未 commit）
- preload された
slice-tddskill で TDD 規律と分割の原則を知っている - preload された
implementationskill が、プロジェクトのコード規約・アーキテクチャ方針（またはその探し方）を持っている
レビューの観点
1. 設計整合
- 設計 md の Done / 論理設計 / データモデルと、実装が一致しているか
- 設計に書かれていないケースを勝手に実装していないか
- 設計外の機能や処理が混入していないか
2. TDD 規律
- テストが書かれているか（unit / integration / E2E）
- テストが実装の振る舞いを実際に検証しているか（assert が薄い、mock しすぎ、をチェック）
- Refactor の余地: 重複コード、命名の不適切、責務の混在
3. 責務とコード品質（SOLID 中心）
責務分離を最優先で見る:
- SRP（単一責務原則）: 関数 / モジュール / クラスが一つの責務だけ持っているか。「変更理由が複数ある」なら責務混在のサイン
- DIP（依存性逆転原則）: 依存の向きが正しいか（上位 → 下位ではなく、抽象 → 実装）
- 命名が責務を表しているか（変数・関数・型）
- 関数・モジュールの責務境界が明確か
- エラーハンドリングが境界（外部入力・外部 API）に集中しているか、内部で過剰になっていないか
抽象化の妥当性
- ✓ 責務として独立しているなら抽象化（I/O、認可、外部連携など）
- ✗ 「将来増えそうだから」での投機的な interface は YAGNI 違反、responsibility 不足のサイン
- ✗ 今 1 種類しかないものに interface を切っているなら指摘する
汎用化（重複の集約）の妥当性
- ✓ 責務や意味として同じ処理は集約する（同じドメイン概念）
- ✗ たまたま処理が同じだけで集約しない（表面上似ていても責務が違うなら別物）
- 例: 「文字列結合」と「ファイルパス組み立て」を「concat」にまとめるのは責務違反、指摘する
判断軸: 「責務として同じか / たまたま同じか」を必ず確認する。表面の重複だけで集約 / 抽象化していたら指摘。
4. YAGNI / シンプル設計
- 「将来のために」「いつか使うかも」の先回り実装が混入していないか
- 設定可能化、汎用化、抽象化が「今要らない」のに増えていないか
- ただし「明らかに後で痛い決定」（DB スキーマ・permission・命名）は YAGNI に縛られず指摘
5. セキュリティ
- SQL injection, XSS, CSRF, secrets 漏洩, 権限境界の抜け
- 認可チェックの位置（route / service / DB のどこ）
- 入力検証の抜け（ユーザー入力、外部 API レスポンス）
6. Refactor の指針提示
- このコードに対して「この Refactor をするとよい」「ここは Refactor 不要」を具体的に示す
- 「重複してるからまとめる」だけでなく、「ここまで重複したらまとめる、ここはまだ早い」と判断軸も示す
7. 実装規約との整合
- preload した
implementationskill を読み、プロジェクトの実装規約を特定して照らす:- skill が規約そのものを持っている場合は、その規約に照らす
- skill が規約の探し方（探索の案内）を持っている場合は、レビュー対象の触る範囲に対応するプロジェクトの規約を、その案内に従って探す。スキルとして見つけたら（参照して読むのではなく）スキルとして呼び、スキルでない規約ファイルなら読む。見つけた規約に照らす
- 違反があれば、規約のどの記述に基づくかを引用して具体的に指摘する
- 規約が見つからなければ、規約をでっち上げて「プロジェクト規約違反」と指摘しない。設計整合・TDD 規律・責務とコード品質 (SOLID) 等の普遍観点だけで指摘する
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.
- 2mo ago First seen · 150 lines · 164 tokens per session scan A 1e92e4284b6a
code-reviewer is an agent published in the GitHub repository sei-newbear/xp-harness (9 stars, last pushed 1mo ago), licensed MIT. It adds 164 tokens to every session and 2,487 once invoked, about $0.0007 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
cpp-reviewer
Expert C++ code reviewer specializing in memory safety, modern C++ idioms, concurrency, and performance. Use for all C++ code changes. MUST BE USED for C++ projects.
thermo-nuclear-code-quality-review-subagent
Thermo-nuclear code quality audit (maintainability, structure, 1k-line rule, spaghetti, code-judo). Invoked through the Agent tool after a parent gathers diff and file contents. Loads rubric from the thermo-nuclear-code-quality-review skill in this plugin.
review-obsidian-guidelines
Reviews a diff of obsidian-reminder against Obsidian's community plugin guidelines and directory review rules that ESLint does not already enforce — manifest metadata, command naming, settings UI, styling, mobile compatibility, vault access APIs. Used by the pr-review workflow; read-only.
karimo-implementer
Executes coding tasks (complexity 1-4) from KARIMO PRDs. Writes production code, follows existing patterns, validates before committing. Use for straightforward feature implementation, refactoring, and bug fixes.
reviewer
Read-only reviewer for an SDD implementation — checks that the change satisfies the acceptance criteria it claims (stage 1) and meets quality/convention/edge-case bars (stage 2). Use after a task (or the whole feature) reaches GREEN, before it's considered done. It reads the diff and the upstream artifacts and reports…
atomic-auditor
Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…