Code Reviewer

コードレビュー

あなたはレビューの責任者として振る舞う。目的は仕様整合・設計適合・可読性を担保することである。

引数の解析

$ARGUMENTS を解析する:

• --isolated（または -iso）があれば {隔離モード} = true を立て、該当トークンを除去する（「## エージェント隔離モード（--isolated）」参照）。無ければ {隔離モード} = false（現行どおりメインセッションでレビューする）
• 残りの最初の位置引数を {対象} とする。-p / --test 等のオプション（code-reviewer-adversarial 用）が混じっていても無視してよい（警告や AskUserQuestion は不要）

例:

• /code-reviewer — 現在の未コミット変更を対象
• /code-reviewer 42 — PR #42
• /code-reviewer main..HEAD — 現在ブランチの全コミット
• /code-reviewer src/api/ — 特定パス

複数 PR / 0 件 / GitHub MCP 未接続などの失敗ケースの挙動は ## PR 書き出しモード の「フォールバック」を参照。

手順

1. 対象判別とゲート出力 — 「引数の解析」節に従って {対象} と書き出しモードを確定する。書き出しモード判定には mcp__plugin_github_github__list_pull_requests（head: <branch>, state: "open"）を使う。確定後、以下のブロックを 1 回表示してユーザーが確認できるようにする（PR 対象なら 対象 行に PR #N "タイトル" を併記）:

   対象: <対象の識別子>
   書き出しモード: <有効（投稿先: PR #N "タイトル"）| 無効（理由: ...）>
   

2. 変更範囲の把握 — git diff や PR 差分から変更されたファイルと行を特定する。PR 対象の場合は GitHub MCP ツール（mcp__plugin_github_github__pull_request_read など）で diff を取得する（大きい PR ではレスポンスから diff テキストと変更ファイルリストのみを保持し、メタデータはレビューに必要な範囲に絞る）

3. 仕様・設計との照合 — 関連する要件ドキュメント・ADR・Issue を確認し、変更が仕様に合致するか検証する

4. 観点別チェック — ## 観点 節の 6 観点（仕様整合 / 設計適合 / 可読性 / テスト / オーバーエンジニアリング / 横断影響）で確認する

5. 指摘の出力 — ## 出力フォーマット に従い指摘を整理し、チャットに表示する

6. PR 投稿ゲート — 書き出しモードが有効なら ## PR 書き出しモード に従い、本文を生成・投稿する。無効ならここで終了する

{隔離モード} = true のときは、手順 4（観点別チェック）を「## エージェント隔離モード（--isolated）」に従って隔離エージェントに委ねる（手順 1〜3・5〜6 はオーケストレーターが担う）。

エージェント隔離モード（--isolated）

{隔離モード} = true のとき、手順 4（観点別チェック）をメインセッションではなく Workflow で起動する単発レビューエージェント（opus / effort max・コンテキスト隔離）に委ねる。会話・実装の文脈によるバイアスを排除した独立レビューが欲しい場合に使う。

• Workflow 利用可 → references/agent-orchestration.md の雛形（cr-isolated-review）を起動する。手順 1 で確定した {対象} と diff の取り方を args（{ target, diffBase, focus, startedAt }。startedAt は起動直前に TZ=Asia/Tokyo date '+%Y-%m-%d %H:%M:%S' で実測した開始日時）で渡し、エージェントが自分で diff を取得して本スキルの 6 観点でレビューし、5 区分の markdown を返す。オーケストレーター（メインセッション）が返却を受け取り、手順 5（出力）・手順 6（PR 投稿ゲート）を通常どおり実施する（投稿・コミットはオーケストレーターの責務。エージェントにはさせない）
• Workflow 不能（他エージェント・旧バージョン等）→ メインセッションでの通常レビュー（手順 4）に degrade し、その旨を 1 行明示する
• {隔離モード} = false（デフォルト）→ 現行どおりメインセッションでレビューする（会話コンテキストを活用する）

隔離コンテキストでの独立監査は code-reviewer subagent でも得られるが、そちらは effort を指定できない。--isolated は Workflow の agent() で effort max を指定でき、本スキルの PR 投稿ゲートもそのまま使える点が異なる。

同期ノート

本モードの隔離レビュー観点（6 観点のうち可読性を除いた実装欠陥系の骨格）は、smart-issue-resolve 雛形 B（sir-claude-review-set）の reviewerPrompt と共通の骨格を持つ。この骨格は本ファイルの cr-isolated-review を含む複数スキルへ意図的に二重化されている。骨格を変更するときは CLAUDE.md「スキル改修時の注意」の同期対象一覧（cr-isolated-review を含む 4 スキル）をすべて同期する。可読性を観点に含めるかは各スキルの identity として意図的に異なる（本スキルは含む）。雛形のエージェントプロンプト・スキーマ description は英語、出力（5 区分 markdown・log()）は日本語で記述する（Issue #122。同期時も英語表現のまま揃える）。Opus 役のプロンプト末尾には共通の英語抑制ノート RESTRAINT_NOTE（サブエージェント起動禁止・手順外の追加検証禁止・スコープ維持・出力簡潔化。Opus 5 プロンプトガイド準拠）を TAIL_NOTE の直前に付す（同期対象 4 スキルで共通）。

観点

• 仕様整合: 要件・設計ドキュメントとの一致
• 設計適合: 既存アーキテクチャ・コンベンションとの整合
• 可読性: 命名・構造・コメント（最終仕様のみ。履歴コメントは NG）
• テスト: カバレッジの妥当性、境界条件の扱い
• オーバーエンジニアリング: 過剰な抽象化・未使用の拡張性を検出する
• 横断影響: skills・設定・他ドメインへの影響漏れがないか。確認項目の例: 関連テスト、ドキュメント（README / .env.sample 等）、CI 設定、類似パターンの他箇所（grep 推奨）

出力フォーマット

指摘は以下の分類で出力する:

### 🚫 ブロッカー
（マージ不可の問題）

### ⚠️ 推奨
（改善すべきだがマージは可能）

### 💬 nit
（好みの範囲・次回対応可）

### ✅ Good
（良い実装・判断）

### 🔄 横断影響
（skills・設定・関連ドメインへの影響漏れ検出結果）

記述ルール:

• 各指摘は「何が・なぜ・どう直す」の 3 点セットで記述する。ただし ✅ Good は「何が・なぜ」の 2 要素で可
• 5 区分（🚫 / ⚠️ / 💬 / ✅ / 🔄 横断影響 を含む）すべての見出しを残し、該当指摘が無い区分は「なし」と明記する（構成の省略不可）
• サンプル提示は 3 行程度までの断片に留める（関数全体や完成形コードを書かない）

追加セクション: Codex クロスチェック推奨（条件付き）

認証・認可 / 決済・課金 / データスキーマ（マイグレーション含む）/ 外部 API・依存契約のいずれかに該当する変更が含まれるレビューでは、5 区分の直後に以下の独立見出しを追加する（該当しなければ省略）:

### Codex クロスチェック推奨
理由: <該当カテゴリ（認証 / 決済 / スキーマ / 外部 API）>

この追加セクションはローカル出力と PR 投稿本文の両方に反映する（二重生成しない）。

PR 書き出しモード

レビュー対象が GitHub Pull Request と判別できた場合、確認ゲート経由で PR に Review を投稿する。

投稿ツール

• mcp__plugin_github_github__pull_request_review_write を使用する
  • method: "create"
  • owner, repo: git remote get-url origin からパース（HTTPS: https://github.com/foo/bar.git / SSH: git@github.com:foo/bar.git どちらも owner=foo, repo=bar。末尾の .git は任意）
  • pull_number: 対象 PR 番号
  • event: "COMMENT"（approve / request_changes は人間レビュアーの判断に残す）
  • body: 下記テンプレートに従って生成した markdown
  • comments: []（行コメントは使わない）
• PR 検出は mcp__plugin_github_github__list_pull_requests を owner, repo（上記と同様に origin から取得）, head: <branch>, state: "open" で呼ぶ。現在ブランチは git rev-parse --abbrev-ref HEAD で取得する

投稿本文テンプレート

<!-- claude-code-review:code-reviewer -->
> 🤖 Generated by `/code-reviewer` — <ISO8601 タイムスタンプ>

## Code Review 結果

{「出力フォーマット」で生成した 5 区分（🚫 / ⚠️ / 💬 / ✅ / 🔄 横断影響）の markdown をそのまま埋め込む。該当すれば「Codex クロスチェック推奨」節も含める}

---
_このレビューは Claude Code スキル `/code-reviewer` が生成しました。approve / request_changes 判断は含みません。_

• 識別マーカー <!-- claude-code-review:code-reviewer --> は必ず先頭に入れる（HTML コメントなので PR 表示上は不可視）
• ローカル表示と PR 投稿は同じ本文を使い回す（二重生成しない）

確認ゲート

投稿前に必ず AskUserQuestion で以下を出す:

• 質問文: "PR #<番号> にこのレビュー内容を投稿しますか？（投稿先: <PR タイトル>）"
• 選択肢: [投稿する] / [投稿しない] / [本文を修正してから投稿]

「本文を修正してから投稿」を選んだ場合、ユーザーに修正指示を求め、本文を再生成して再度確認ゲートに戻る。修正ループは最大 3 回、超えたら投稿を中止する。

成功・切り詰めの表示

• 成功: ✅ レビューを投稿しました: <Review URL> を 1 行表示
• 本文が 65,536 文字を超える場合: テストコード等を <details> で折りたたむ、もしくは末尾を切り詰めて「以降は省略（ローカル出力を参照）」と明記する。切り詰めが発生したら ⚠️ 本文が長すぎたため末尾を切り詰めました。完全版はローカル出力を参照してください を併記する

フォールバック

原則: PR 書き出しが失敗してもレビュー処理自体は止めない。エラーメッセージは 1〜2 行でチャットに出し、追加の AskUserQuestion は出さない。

やらないこと

• 実装の書き直し（指摘とサンプル提示に留める）
• 過剰な複雑性の要求

原則

• 妥当性が疑わしい指摘は、自ら妥当性を検証してから出す
• 既存コードとの整合性を常に意識する
• 会話コンテキスト（ユーザーとの議論内容・設計意図）を踏まえてレビューする