sc-code-review

コードレビュー スキル

PAL MCP の複数モデル合意を利用した包括的なコードレビューです。セキュリティ、品質、パフォーマンス、アーキテクチャに重点を置いて、最近のコミット、ステージング済みの変更、またはブランチ間の比較をレビューします。

クイックスタート

# Review last 5 commits (default)
/sc:code-review

# Review staged changes
/sc:code-review --staged

# Compare feature branch against main
/sc:code-review --branch main

# Security-focused review
/sc:code-review commits=3 --focus security

# Post review as PR comment
/sc:code-review --branch main --post-pr

基本方針：早めに、何度でも確認する

このスキルでは、あらゆる判断の場面で積極的に AskUserQuestion を使用します。 コードレビューは主観的なものです。何が重要かは状況によって異なり、レビュアーの優先事項についての思い込みは、しばしば誤っています。質問するコストは低く、誤った範囲をレビューしたり、ユーザーが重視する点を見落としたりするコストは高くなります。

対話型チェックポイント：

• レビューの前 — レビュー範囲とユーザーが重視する点を確認します
• 差分が大きい場合 — まず何に注目するかをユーザーに選んでもらいます
• 分類が曖昧な場合 — 重大度レベルについて質問します
• モデルの意見が異なる場合 — 問題の重大度についてユーザーに判断してもらいます
• 検出事項を提示した後 — 次に何をするか（修正、再レビュー、PR への投稿）を質問します
• トレードオフがある場合 — 暗黙に選択せず、明示的に提示します
• 重大度が「Critical」または「High」の検出事項について — 最終決定の前に、ユーザーに重大度を確認します

ユーザーは、一方的にレポートを受け取るのではなく、自分でレビューを進行していると感じられる必要があります。

動作フロー

1. 解析 - 引数からレビューのモード、注目領域、コミット範囲を抽出します
2. 検証 - Git の状態、ブランチの存在、ステージング済みの変更を検証します
3. 範囲の確認 - ユーザーと対話し、レビュー範囲を確認します
4. 検出 - mcp__pal__listmodels を使って利用可能なモデルを一覧表示します
5. 収集 - Git の差分、変更ファイル、コミット履歴を収集します
6. 分類 - 変更ファイルをレビューの注目領域に対応付けます
7. 大きな差分への対応 - 大規模な変更に対する対話型の分割方法を決定します
8. レビュー - PAL MCP の複数モデル評価で合意を形成します
9. 意見の相違を解決 - モデル間の意見の食い違いをユーザーが裁定します
10. 検出事項の検証 - 重大度が「Critical」または「High」の項目をユーザーが確認します
11. フォーマット - GitHub の PR コメント形式で検出事項を提示します
12. フォローアップ - 次に何をするか（修正、詳細調査、PR への投稿）をユーザーに質問します
13. 投稿 - 必要に応じて gh CLI で PR に投稿します

フラグ

フラグ	型	デフォルト	説明
commits	int	5	レビューする最近のコミット数
--staged	bool	false	ステージング済みの変更のみをレビューします
--branch	string	-	現在のブランチと対象ブランチを比較します
--focus	string	full	注目領域：security、performance、quality、architecture、full
--post-pr	bool	false	レビューを PR コメントとして投稿します
--models	int	2	合意形成に使用するモデル数（2～5）

レビューモード

各モードは相互に排他的です。

モード	トリガー	Git コマンド
コミット	デフォルトまたは commits=N	git diff -U10 HEAD~N..HEAD
ステージング済み	--staged	git diff -U10 --cached
ブランチ	--branch <target>	git diff -U10 origin/<target>...HEAD

フェーズ 1：Git の状態を検証する

# Verify git repository
git rev-parse --is-inside-work-tree

# Get current branch
git branch --show-current

モードごとの検証：

• コミット：git rev-list --count HEAD が N 以上であることを確認します
• ステージング済み：git diff --cached --name-only の結果が空でないことを確認します
• ブランチ：git rev-parse --verify "origin/$TARGET" が存在することを確認します

フェーズ 1b：レビュー範囲を確認する

Git のコンテキストを収集した後、概要を提示し、ユーザーに確認または調整してもらいます。

AskUserQuestion:
  question: "Here's what I'll be reviewing. Does this scope look right?"
  header: "Scope"
  multiSelect: false
  options:
    - label: "Looks good — proceed"
      description: "<N files changed, +X/-Y lines, commits/staged/branch summary>"
    - label: "Too much — narrow scope"
      description: "I only want to review a subset of these changes"
    - label: "Too little — expand scope"
      description: "Include more commits or compare against a different branch"
    - label: "Different focus"
      description: "I want to focus on a specific area (security, performance, etc.)"

「多すぎる — 範囲を狭める」の場合：注目するファイルまたはディレクトリを質問します。

AskUserQuestion:
  question: "Which areas should I focus the review on?"
  header: "Focus"
  multiSelect: true
  options:
    - label: "Backend (app/)"
      description: "<N files, +X/-Y lines in app/>"
    - label: "Frontend (frontend/)"
      description: "<N files, +X/-Y lines in frontend/>"
    - label: "Tests"
      description: "<N files, +X/-Y lines in tests/>"
    - label: "Config/Infra"
      description: "<N files in Docker, CI, config>"

「少なすぎる — 範囲を広げる」の場合：どのように範囲を広げるか（コミット数を増やす、別のブランチにする）を質問します。

「別の注目領域」の場合：使用するレビューの注目領域を質問し、--focus フラグの設定を上書きします。

フェーズ 2：モデルを検出する

mcp__pal__listmodels を呼び出し、利用可能なモデルを取得します。スコア上位の N 個を選択し、多様性を高めるため、異なるプロバイダーのモデルを優先します。

選択基準：

1. スコアの降順で並べ替えます
2. 可能であれば異なるプロバイダーから選びます
3. 有意義な合意形成のため、最低 2 つのモデルを使用します

Phase 3: Git コンテキストの収集

選択したレビュー モードに応じて、以下を収集します。

データ	目的
git diff -U10 ...	コンテキストを拡張した完全な差分
git diff --stat ...	変更統計
git log --oneline ...	コミットの概要
変更されたファイルの一覧	ファイルの分類

Phase 4: 変更されたファイルの分類

パターン	カテゴリ	レビューの重点
*.py、*.ts、*.go、*.rs	ソースコード	セキュリティ、SOLID、パフォーマンス
tests/**、*_test.*	テストコード	カバレッジ、エッジケース、アサーション
*.yml、*.yaml、*.toml	設定	セキュリティ、正確性
*requirements*、*package*	依存関係	脆弱性、バージョン
Dockerfile*、docker-compose*	インフラストラクチャ	セキュリティ、ベストプラクティス
*.md、*.rst	ドキュメント	正確性、完全性

バイナリファイルはスキップします（記録しますが、差分レビューからは除外します）。

Phase 5: 大規模な差分の処理

差分が約1000行を超える場合は、対応方法をユーザーに確認します。

AskUserQuestion:
  question: "The diff is large (~<N> lines across <M> files). How should I handle it?"
  header: "Large diff"
  multiSelect: false
  options:
    - label: "Review in chunks by category (Recommended)"
      description: "Group files by type (backend, frontend, tests, config) and review each separately"
    - label: "Focus on highest-risk files only"
      description: "Skip low-risk changes (docs, tests, config) and focus on production code"
    - label: "Review everything in one pass"
      description: "Send the full diff to models — may lose detail on individual files"
    - label: "Let me pick specific files"
      description: "I'll tell you exactly which files to review"

「特定のファイルを選択する」場合：

• 変更されたすべてのファイルとその統計を一覧表示します
• レビューするファイルをユーザーに選択してもらいます
• それに応じて差分の対象を絞り込みます

「カテゴリごとに分割してレビューする」場合：

1. ファイルをカテゴリ（ソース、テスト、設定、ドキュメント）ごとにグループ化します
2. PAL コンセンサスを使用して、各グループを個別にレビューします
3. 検出事項を1つのレポートにまとめます
4. 重複する問題を整理します

「リスクが最も高いファイルのみを対象にする」場合：

• ドキュメント、設定、テストのファイルを除外します
• コンセンサスの対象を本番ソースコードのみに絞ります

Phase 6: PAL MCP コンセンサスの実行

検出されたモデルを使用して mcp__pal__consensus を実行します。

コンセンサスのワークフロー：

• step 1：差分に対する初期分析
• step 2+：各モデルが検出事項を返します
• total_steps = モデルの数 + 1

重点領域別のレビューチェックリスト：

重点領域	確認項目
security	シークレット、インジェクション、認証、入力検証、依存関係
performance	N+1クエリ、複雑度、キャッシュ、メモリリーク
quality	SOLID、命名、エラー処理、型、デッドコード
architecture	パターン、結合度、関心の分離、テスト容易性
full	上記のすべて（デフォルト）

フォールバック：コンセンサスに失敗した場合は、単一モデルでレビューするために mcp__pal__codereview を使用します。

Phase 6a: モデル間の意見の相違を提示

モデル間で問題の深刻度または有無について意見が分かれた場合、自分で意見の相違を解決してはいけません。重要な意見の相違をそれぞれ提示します。

AskUserQuestion:
  question: "Models disagreed on <specific issue>. How should this be classified?"
  header: "Severity"
  multiSelect: false
  options:
    - label: "<Model A's severity> (e.g., Critical)"
      description: "<Model A> flagged this as <severity> because: <reasoning>"
    - label: "<Model B's severity> (e.g., Low)"
      description: "<Model B> considers this <severity> because: <reasoning>"
    - label: "Dismiss this finding"
      description: "This isn't actually an issue — it's intentional or acceptable"

重要な意見の相違ごとに繰り返します（AskUserQuestion の1回の呼び出しにつき最大4件）。深刻度のレベルが変わらない軽微な違いは省略します。

Phase 6b: Critical／High の検出事項を検証

Critical または High に分類された検出事項がある場合、最終レポートに含める前に、ユーザーに確認を求めます。これらの深刻度における誤検出は、信頼を損ないます。

AskUserQuestion:
  question: "I found <N> critical/high issues. Do these look like real problems, or should I reclassify any?"
  header: "Validate"
  multiSelect: true
  options:
    - label: "<Issue 1 summary>"
      description: "[FILE:LINE] — <brief description>. Classified as <severity>"
    - label: "<Issue 2 summary>"
      description: "[FILE:LINE] — <brief description>. Classified as <severity>"
    - label: "<Issue 3 summary>"
      description: "[FILE:LINE] — <brief description>. Classified as <severity>"
    - label: "All look correct"
      description: "Keep all critical/high classifications as-is"

解釈：

• 選択された項目は実際の問題として確認されたものです。現在の深刻度を維持します
• 選択されなかった Critical／High の項目は、注記を添えて Medium に引き下げます
• 「すべて正しい」を選択した場合は、すべてを現状のままにします

Critical または High の検出事項がない場合、この質問は省略します。

検証には mcp__pal__challenge を使用します：

• Critical／High の検出事項ごとに、mcp__pal__challenge を実行して深刻度を検証します
• 元の検出事項と challenge の結果の両方を提示します
• 深刻度の最終判断はユーザーに委ねます

challenge プロンプトの例：

"The code review identified this as a Critical security issue: <issue description>.
Challenge this finding: Is it actually critical? Could it be a false positive?
What's the real-world exploitability? What's the actual severity?"

これにより、誤検出を防ぐための敵対的な検証レイヤーが追加されます。

Phase 7: 出力の整形

## Code Review: Multi-Model Consensus

**Review Mode**: [Commits (last N) | Staged Changes | Branch vs TARGET]
**Files Reviewed**: N files
**Lines Changed**: +X / -Y

---

### Executive Summary
[2-3 sentence overview]

---

### Critical Issues
> Must be addressed before merge

- [ ] **[FILE:LINE]** - [Issue description]
  - **Category**: Security/Performance/Bug Risk
  - **Severity**: Critical
  - **Recommendation**: [Specific fix]

### High Priority
> Should be addressed

- [ ] **[FILE:LINE]** - [Issue description]
  - **Category**: [Category]
  - **Recommendation**: [Specific fix]

### Medium Priority
> Recommended improvements

- [ ] **[FILE:LINE]** - [Issue description]
  - **Recommendation**: [Suggestion]

### Low Priority / Suggestions
> Nice to have

- [ ] [Suggestion]

---

### Positive Observations
- [Good pattern observed]

---

### Review Summary

| Category | Rating | Notes |
|----------|--------|-------|
| Security | X/5 | [Brief note] |
| Code Quality | X/5 | [Brief note] |
| Performance | X/5 | [Brief note] |
| Architecture | X/5 | [Brief note] |
| Test Coverage | X/5 | [Brief note] |

**Overall Assessment**: [APPROVE / REQUEST CHANGES / NEEDS DISCUSSION]

---

### Model Consensus

| Model | Key Findings |
|-------|--------------|
| [Model 1] | [Summary] |
| [Model 2] | [Summary] |

**Agreement Areas**: [Where models agreed]
**Divergent Views**: [Where models differed]

フェーズ 8：レビュー後のフォローアップ

レビュー結果を提示した後は、必ず次に何をしたいかユーザーに尋ねます。

AskUserQuestion:
  question: "Review complete (<overall assessment>). What would you like to do next?"
  header: "Next"
  multiSelect: false
  options:
    - label: "Auto-fix issues"
      description: "Attempt to fix all critical and high issues automatically"
    - label: "Review a specific file in detail"
      description: "Deep-dive into one file that needs closer inspection"
    - label: "Post to PR"
      description: "Post this review as a comment on the current PR"
    - label: "Re-review with different models"
      description: "Run the review again with different model consensus"
    - label: "Done"
      description: "Review is complete — no further action needed"

「問題を自動修正する」の場合：修正する重要度レベルを尋ねます。

AskUserQuestion:
  question: "Which issues should I attempt to fix?"
  header: "Fix scope"
  multiSelect: true
  options:
    - label: "Critical issues (<N>)"
      description: "Must-fix items that block merge"
    - label: "High priority (<N>)"
      description: "Should-fix items"
    - label: "Medium priority (<N>)"
      description: "Recommended improvements"
    - label: "All issues"
      description: "Fix everything that can be automated"

その後、Edit を使って修正を試み、結果を報告します。修正するたびに、続行するか変更を確認するかをユーザーに尋ねます。

「特定のファイルを詳しくレビューする」の場合：

• 変更ファイルの一覧から対象のファイルを尋ねます。
• そのファイルの差分のみを対象に、最大のコンテキスト（-U20）でコンセンサスを再実行します。
• そのファイルの詳細な所見のみを提示します。

「別のモデルで再レビューする」の場合：

• mcp__pal__listmodels を再度実行します。
• 別のモデルを選択してもらいます。
• 新しいモデルセットでレビュー全体を再実行します。

フェーズ 9：PR への投稿（任意）

--post-pr フラグが設定されており、かつ PR のコンテキストにある場合：

PR_NUMBER=$(gh pr view --json number -q .number 2>/dev/null)
gh pr comment $PR_NUMBER --body "<review output>"

MCP 統合

PAL MCP（主要）

ツール	使用するタイミング	目的
mcp__pal__listmodels	常時	利用可能なモデルを確認します
mcp__pal__consensus	デフォルト	複数モデルによるコードレビューのコンセンサス
mcp__pal__codereview	フォールバック	単一モデルによるコードレビュー
mcp__pal__challenge	重大な所見がある場合	重大な問題の重要度を検証します

Rube MCP（任意）

ツール	使用するタイミング	目的
mcp__rube__RUBE_SEARCH_TOOLS	--notify	通知ツールを検索します
mcp__rube__RUBE_MULTI_EXECUTE_TOOL	--notify	レビュー結果を Slack/Jira に送信します

エラー処理

状況	対応
Git リポジトリではない	エラーで終了します
指定範囲にコミットがない	利用可能なコミット数に合わせて N を調整します
ステージ済みの変更がない	git add するよう案内を添えてエラーを返します
ブランチが見つからない	利用可能なブランチを示してエラーを返します
PAL MCP が利用できない	mcp__pal__codereview にフォールバックします
利用可能なモデルがない	エラー — PAL MCP が設定されていません

ツールの連携

• Bash - Git 操作、PR への投稿
• Read - コンテキスト把握のためのソースファイル調査
• Grep - 変更ファイル内のパターン検索
• Edit - 所見に基づく問題の自動修正
• Glob - 大きな差分のファイル検索
• PAL MCP - 複数モデルによるコンセンサスレビュー
• Rube MCP - 外部への通知
• AskUserQuestion - 対話形式での判断ポイント

注記

• 拡張差分コンテキスト（-U10）により、モデルがコードをより適切に理解できます。
• バイナリファイルは記録されますが、差分レビューの対象外です。
• Python ファイルは CLAUDE.md に従って、SOLID 原則に関する追加レビューを受けます。
• レビューの深さは差分のサイズに応じて調整されます（大きな差分は分割されます）。
• 対話形式の検証により、重大な所見に対する誤検知を防ぎます。
• レビューフローはユーザーが主導します。自動処理ではなく、共同で進めます。