# Code Reviewer

> 実装されたコードを仕様整合・設計適合・可読性の観点でレビューする。PR / 変更差分のレビュー、コミット前のセルフレビューに使う。対象が PR なら確認ゲート経由で PR にレビューを投稿する。重要変更は Codex クロスチェックを推奨する。--isolated でコンテキスト隔離した Opus（effort max）エージェントによる単発レビューも可能（Workflow 前提・不能時はメインセッションに degrade）。

- Skill: `mjcreativelab/code-reviewer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add mjcreativelab/code-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mjcreativelab/code-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: mjcreativelab (https://skillmd.com/u/mjcreativelab)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mjcreativelab/code-reviewer

---


# コードレビュー

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

## 引数の解析

`$ARGUMENTS` を解析する:

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

| 判定 | 解釈 | 書き出しモード |
|---|---|---|
| 省略 | 未コミット変更 + 現在ブランチ vs `main` を対象にする | 現在ブランチに open PR が 1 件 → 有効 |
| 存在するファイル/ディレクトリパス | そのパス配下の変更のみ | 無効（PR に紐付かない）|
| 数字のみ | GitHub PR 番号として扱う（GitHub MCP ツールで diff を取得）| 有効 |
| `<ref>..<ref>` を含む | commit 範囲の diff | 無効（PR に紐付かない）|
| ローカル or `origin/` で解決できるブランチ名 | そのブランチ vs `main` の差分 | そのブランチに open PR が 1 件 → 有効 |
| 上記いずれでもない | `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](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 推奨）

## 出力フォーマット

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

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

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

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

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

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

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

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

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

```markdown
### 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` で取得する

### 投稿本文テンプレート

````markdown
<!-- 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>` で折りたたむ、もしくは末尾を切り詰めて「以降は省略（ローカル出力を参照）」と明記する。切り詰めが発生したら `⚠️ 本文が長すぎたため末尾を切り詰めました。完全版はローカル出力を参照してください` を併記する

### フォールバック

| ケース | 挙動 |
|---|---|
| GitHub MCP ツール未接続 | 書き出しモード無効化。ゲート出力に理由を明示し、レビュー処理は通常実行 |
| 対象ブランチの open PR が 0 件（引数省略時）| 書き出しモード無効化。エラーにしない |
| 対象ブランチの open PR が複数 | `AskUserQuestion` で PR 番号を選ばせる（「書き出し不要」選択肢も出す）|
| 指定 PR 番号が存在しない / アクセス権なし | 書き出しモード無効化し理由を明示、レビュー処理は続行 |
| 投稿権限 403 等 | 失敗メッセージを 1 行表示、ローカル出力は残す |
| API 一時エラー | 1 回だけリトライ、再失敗で諦めて手動投稿を案内 |
| 確認ゲートで「投稿しない」 | 正常終了、ローカル出力のみ |
| 修正ループ 3 回超 | 投稿中止、最後の本文をローカルに残す |

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

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

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