ck:code-review

コードレビュー

技術的な厳密さ、根拠に基づく主張、見せかけの応答ではなく検証を重視した敵対的コードレビューです。すべてのレビューには、コードを積極的に破壊しようと試みるレッドチーム分析が含まれます。

入力モード

引数から自動判定します。曖昧な場合、または引数がない場合は、AskUserQuestion で確認します。

入力	モード	レビュー対象
#123 または PR の URL	PR	gh pr diff で取得した PR の差分全体
abc1234（7 文字以上の 16 進数）	コミット	git show による単一コミットの差分
--pending	保留中	git diff によるステージ済みおよび未ステージの変更
（引数なし、最近の変更あり）	デフォルト	コンテキスト内の最近の変更
codebase	コードベース	コードベース全体のスキャン
codebase parallel	コードベース＋	複数レビュアーによる並列監査

判定の詳細： references/input-mode-resolution.md

引数がない場合

引数なしで呼び出され、コンテキスト内に最近の変更がない場合は、ヘッダー「Review Target」、質問「What would you like to review?」を指定して AskUserQuestion を使用します。

選択肢	説明
保留中の変更	ステージ済み／未ステージの git 差分をレビュー
PR 番号を入力	特定の PR を取得してレビュー
コミットハッシュを入力	特定のコミットをレビュー
コードベース全体をスキャン	コードベースを詳細に分析
コードベースを並列監査	複数レビュアーによるコードベースのスキャン

基本原則

常に YAGNI、KISS、DRY を守ります。社会的な配慮より技術的な正しさを優先します。 正直に、率直に、要点を述べ、簡潔に伝えます。

実装する前に検証します。推測する前に質問します。主張する前に根拠を示します。

プラクティス

プラクティス	使用するタイミング	参照
仕様準拠	計画／仕様に基づく実装後、品質レビューの前	references/spec-compliance-review.md
敵対的レビュー	常時有効のステージ 3 — コードを積極的に破壊しようと試みる	references/adversarial-review.md
フィードバックの受け取り	不明確なフィードバック、外部レビュアー、優先順位付けが必要な場合	references/code-review-reception.md
レビューの依頼	タスク後、マージ前、問題で行き詰まったとき	references/requesting-code-review.md
検証ゲート	完了の主張、コミット、PR の前	references/verification-before-completion.md
エッジケースの調査	実装後、レビュー前	references/edge-case-scouting.md
チェックリストレビュー	リリース前、/ck:ship パイプライン、セキュリティ監査	references/checklist-workflow.md
タスク管理レビュー	複数ファイルにまたがる機能（3 ファイル以上）、並列レビュアー、修正サイクル	references/task-management-reviews.md

クイック判定ツリー

SITUATION?
│
├─ Input mode? → Resolve diff (references/input-mode-resolution.md)
│   ├─ #PR / URL → fetch PR diff
│   ├─ commit hash → git show
│   ├─ --pending → git diff (staged + unstaged)
│   ├─ codebase → full scan (references/codebase-scan-workflow.md)
│   ├─ codebase parallel → parallel audit (references/parallel-review-workflow.md)
│   └─ default → recent changes in context
│
├─ Received feedback → STOP if unclear, verify if external, implement if human partner
├─ Completed work from plan/spec:
│   ├─ Stage 1: Spec compliance review (references/spec-compliance-review.md)
│   │   └─ PASS? → Stage 2 │ FAIL? → Fix → Re-review Stage 1
│   ├─ Stage 2: Code quality review (code-reviewer subagent)
│   │   └─ Scout edge cases → Review standards, performance
│   └─ Stage 3: Adversarial review (references/adversarial-review.md) [ALWAYS-ON]
│       └─ Red-team the code → Adjudicate → Accept/Reject findings
├─ Completed work (no plan) → Scout → Code quality → Adversarial review
├─ Pre-landing / ship → Load checklists → Two-pass review → Adversarial review
├─ Multi-file feature (3+ files) → Create review pipeline tasks (scout→review→adversarial→fix→verify)
└─ About to claim status → RUN verification command FIRST

3 段階のレビュープロトコル

ステージ 1 — 仕様準拠（references/spec-compliance-review.md を読み込む）

• コードは依頼内容に合っていますか？
• 要件の抜けはありませんか？正当化できない追加はありませんか？
• ステージ 2 の前に必ず合格する必要があります

ステージ 2 — コード品質（code-reviewer サブエージェント）

• 仕様準拠に合格した後にのみ実行します
• 標準、セキュリティ、パフォーマンス、エッジケースを確認します

ステージ 3 — 敵対的レビュー（references/adversarial-review.md を読み込む）

• ステージ 2 の合格後、スコープゲートの条件に従って実行します（対象が 2 ファイル以下、30 行以下で、セキュリティ関連ファイルがない場合はスキップ）
• 実行環境、フレームワーク、コンテキストファイルを踏まえて敵対的レビュアーを起動します
• 発見対象：セキュリティホール、誤った前提、リソース枯渇、競合状態、サプライチェーン、可観測性の欠落
• 出力：各指摘に対し「承認（修正必須）／却下（誤検知）／保留（GitHub issue）」の判定
• 重大な指摘がある場合はマージをブロックします。再レビューでは差分のみを対象とする最適化を使用します

フィードバックの受け取り

手順： 読む → 理解する → 検証する → 評価する → 返答する → 実装する 見せかけの同意はしません。実装前に検証します。誤りがあれば反論します。

プロトコル全文： references/code-review-reception.md

レビューの依頼

タイミング： 各タスクの完了後、主要機能の実装後、マージ前

手順：

1. まずエッジケースを調査します（下記を参照）
2. SHA を取得します：BASE_SHA=$(git rev-parse HEAD~1) と HEAD_SHA=$(git rev-parse HEAD)
3. WHAT、PLAN、BASE_SHA、HEAD_SHA、DESCRIPTION を指定して、code-reviewer サブエージェントを起動します
4. Critical の指摘は直ちに修正し、Important の指摘は先に進む前に修正します

完全なプロトコル： references/requesting-code-review.md

エッジケースの調査

タイミング： 実装後、code-reviewer に依頼する前

手順：

1. エッジケースに焦点を当てたプロンプトで /ck:scout を実行します
2. Scout が影響を受けるファイル、データフロー、エラーパス、境界条件を分析します
3. Scout の調査結果を確認し、潜在的な問題を検討します
4. コードレビューの前に、重大な見落としに対処します

完全なプロトコル： references/edge-case-scouting.md

タスク管理型レビューのパイプライン

タイミング： 複数ファイルにまたがる機能（変更ファイルが 3 つ以上）、並列の code-reviewer の担当範囲、Critical の修正を繰り返すレビューサイクル。

フォールバック： タスクツール（TaskCreate/TaskUpdate/TaskGet/TaskList）は CLI 専用のため、VSCode 拡張機能では利用できません。エラーが発生した場合は、TodoWrite で進捗を管理し、パイプラインを順次実行します。レビューの品質は変わりません。

パイプライン： scout → review → adversarial → fix → verify（それぞれ依存関係チェーンを持つタスク）

TaskCreate: "Scout edge cases"         → pending
TaskCreate: "Review implementation"    → pending, blockedBy: [scout]
TaskCreate: "Adversarial review"       → pending, blockedBy: [review]
TaskCreate: "Fix critical issues"      → pending, blockedBy: [adversarial]
TaskCreate: "Verify fixes pass"        → pending, blockedBy: [fix]

並列レビュー： 独立したファイルグループ（例：バックエンドとフロントエンド）ごとに範囲を絞った code-reviewer サブエージェントを起動します。fix タスクは、すべてのレビュー担当者が完了するまでブロックされます。

再レビューサイクル： 修正によって新たな問題が生じた場合は、サイクル 2 のレビュータスクを作成します。サイクルは最大 3 回までとし、その後はユーザーにエスカレーションします。

完全なプロトコル： references/task-management-reviews.md

検証ゲート

鉄則： 新たな検証の証拠なしに、完了を主張してはなりません

ゲート： コマンドを特定 → 全体を実行 → 出力を読む → 検証が確認されたことを確かめる → その後で主張する

要件：

• テストが成功：出力で失敗数が 0 と表示されている
• ビルドが成功：終了コードが 0
• バグが修正済み：元の症状に対するテストが成功する
• 要件を満たしている：チェックリストで確認済み

危険信号： 「はず」「おそらく」「そう見える」といった表現、検証前に満足すること、エージェントの報告を鵜呑みにすること

完全なプロトコル： references/verification-before-completion.md

ワークフローとの連携

• サブエージェント駆動： 次のタスクに進む前に、Scout → Review → Adversarial → Verify
• プルリクエスト： Scout → Code quality → Adversarial → Merge
• タスクパイプライン： 依存関係を設定してレビュータスクを作成 → チェーンに沿って自動的にブロック解除
• Cook の引き継ぎ： Cook がフェーズを完了 → レビューパイプラインのタスク（Adversarial を含む）を実行 → すべて完了 → Cook が続行
• PR レビュー： /code-review #123 → 差分を取得 → PR の変更を対象に 3 段階のレビューを実行
• コミットレビュー： /code-review abc1234 → 指定されたコミットを完全なパイプラインでレビュー

コードベース分析のサブコマンド

サブコマンド	参照先	目的
/ck:code-review codebase	references/codebase-scan-workflow.md	コードベースをスキャンして分析する
/ck:code-review codebase parallel	references/parallel-review-workflow.md	エッジケースを徹底的に検討し、その後並列で検証する

要点

1. まず入力モードを解決し、何をレビューするのか把握します
2. 社交的な振る舞いより技術的な厳密さを優先します
3. レビュー前にエッジケースを調査します
4. 例外なく、すべてのレビューで Adversarial レビューを行います
5. 主張する前に証拠を確認します

検証する。調査する。レッドチームで検討する。問い直す。それから実装する。証拠を確認する。その後で主張する。