Menu
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を design.md にまとめる。
| name | code-review |
| description | 実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。 |
実装者とは別のエージェントが、3つの独立した観点でコードをレビューする。 実装者バイアスを排除し、仕様との乖離・品質劣化・脆弱性を検出する。
入力: REQ パス（例: requirements/REQ-001/）+ テスト全 GREEN の実装コード + requirements.md 全文
出力: 3観点のレビュー報告（MUST/SHOULD/CONSIDER 指摘）+ 修正済みコード
原則: 実装した者がレビューしても、自分の思い込みは見つけられない。
3観点レビュー（仕様→品質→セキュリティ）を省略するな
1段階でも飛ばした？ それはレビューではない。チェックリストの消化だ。
3観点レビュー（仕様・品質・セキュリティ）を実施する。
常に:
例外（人間パートナーに確認すること）:
digraph code_review {
rankdir=TB;
input [label="実装完了\nテスト全GREEN", shape=ellipse];
subgraph cluster_parallel {
label="並列レビュー";
style=dashed;
spec [label="仕様準拠レビュー\n(spec-compliance-reviewer)", shape=box, style=filled, fillcolor="#cce5ff"];
quality [label="コード品質レビュー\n(quality-reviewer)", shape=box, style=filled, fillcolor="#ccffcc"];
security [label="セキュリティレビュー\n(security-reviewer)", shape=box, style=filled, fillcolor="#ffcccc"];
}
collect [label="全指摘を\n一括収集", shape=box];
has_must [label="MUST\n指摘あり?", shape=diamond];
analyze [label="依存分析\nファイル重複チェック", shape=box];
subgraph cluster_fix {
label="修正フェーズ";
style=dashed;
fix_shared [label="Phase 1: 共有部分\n(型, interface, 共通関数)\n1 implementer 直列", shape=box, style=filled, fillcolor="#ffffcc"];
fix_parallel [label="Phase 2: 独立部分\n複数 implementer 並列", shape=box, style=filled, fillcolor="#ffffcc"];
}
re_review [label="再レビュー\nMUST指摘があった\n観点のみ並列", shape=box, style=filled, fillcolor="#e6ccff"];
done [label="レビュー完了", shape=ellipse];
input -> spec;
input -> quality;
input -> security;
spec -> collect;
quality -> collect;
security -> collect;
collect -> has_must;
has_must -> done [label="なし"];
has_must -> analyze [label="あり"];
analyze -> fix_shared;
fix_shared -> fix_parallel;
fix_parallel -> re_review;
re_review -> has_must [label="ループ\n最大3回"];
}
3つのレビュアーは独立した観点を持つ。同じコードを読むだけ（read-only）なので並列実行する。
実装が要件・仕様を満たしているかを検証する。
コードの保守性・可読性・設計品質を検証する。
セキュリティ上の脆弱性がないかを検証する。
MUST 指摘がある場合、修正前に依存分析を行う。
MUST 指摘が少数（3件以下）かつ affected files が少ない場合は、依存分析をスキップして 1 implementer にまとめて渡してよい。
修正 → 再レビュー: 最大3回
3回修正しても通らない場合:
├─ 仕様レビュー不合格 → タスク分割を検討 or 人間エスカレート
└─ 品質/セキュリティレビュー不合格 → Opus で1回リトライ → ダメなら人間エスカレート
最大4回（通常3回 + モデルエスカレート1回）で打ち切り。 無限ループに入るな。3回目の修正で同じ指摘が出たら、根本的な設計問題だ。
Note: workflow.md の Safety Limits では「レビュー→修正ループ上限 2周」と定義されているが、本スキルではより詳細な上限（修正3回+モデルエスカレート1回=最大4回）を定義する。本スキルの定義が優先される。
| 品質 | 良い | 悪い |
|---|---|---|
| 具体的 | 「L42: null チェックが漏れている。user が undefined の場合に例外が発生する」 | 「エラーハンドリングが甘い」 |
| 修正案付き | 問題 + 修正の方向性を提示 | 問題の指摘だけで終わる |
| 根拠あり | ルール・仕様・脆弱性 DB を根拠に指摘 | 「なんとなく良くない」 |
| 優先度明示 | MUST / SHOULD / CONSIDER で分類 | 全部同じ重みで列挙 |
| 再現可能 | 具体的な入力やシナリオで再現手順を示す | 「こういうケースがありそう」 |
| 言い訳 | 現実 |
|---|---|
| 「テストが通っているからレビュー不要」 | テストは仕様の一部しかカバーしない。レビューは別の観点を持つ |
| 「小さい変更だからスキップ」 | 1行の変更でセキュリティホールは作れる |
| 「急いでいるからレビューは後で」 | 後でやるレビューは永遠に来ない |
| 「自分でレビューした」 | 実装者バイアスで自分のミスは見えない |
| 「セキュリティは内部ツールだから関係ない」 | 内部ツールも攻撃対象になる。SSRF、権限昇格 |
| 「前回と同じパターンだからレビュー不要」 | 同じパターンでも文脈が違えばバグは違う |
以下のどれかに当てはまったら、レビュープロセスをやり直せ。
Stage 1 - 仕様準拠レビュー:
MUST: POST /users のレスポンスに id フィールドがない（仕様では必須）
SHOULD: エラーレスポンスの形式が仕様の ErrorResponse スキーマと不一致
Stage 2 - 品質レビュー:
MUST: createUser 関数が80行。バリデーション・変換・保存を分離せよ
SHOULD: userRouter 内の重複したエラーハンドリングをミドルウェアに抽出
CONSIDER: DTO と Entity の変換を専用関数に分離
Stage 3 - セキュリティレビュー:
MUST: req.body をバリデーションなしで直接 DB クエリに使用（SQLインジェクション）
MUST: パスワードが平文で保存されている
SHOULD: レスポンスに内部エラーの詳細が露出（スタックトレース）
レビュー完了前に確認:
| 問題 | 解決策 |
|---|---|
| 仕様が不明確でレビューできない | 人間パートナーに仕様の明確化を依頼する |
| 同じ指摘が修正後も繰り返される | 設計に根本的な問題がある。タスク分割か設計見直し |
| レビュー指摘が大量すぎる | MUST だけ先に修正。SHOULD は次のイテレーション |
| セキュリティ判断に自信がない | security-reviewer に具体的な攻撃シナリオを生成させる |
レビュー指摘を人間パートナーに提示する際は、以下の構造で整理すること。 レビューエージェントの生出力をそのまま貼らない。
| # | 重要度 | ファイル | 指摘内容（1行） | 判断ポイント |
|---|---|---|---|---|
| 1 | MUST | xxx.md | [指摘の要約] | [人間が判断すべき論点] |
| 2 | SHOULD | yyy.ts | [指摘の要約] | [人間が判断すべき論点] |
あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントにディスパッチする。
前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md を特定しろ。タスクのコンテキスト（plan、直前のステップの出力）に REQ パスが含まれていればそれを使う。見つからなければ requirements/ を確認し、候補を人間パートナーに AskUserQuestion で提示して選択してもらう。推測で REQ を決めるな。必ず人間に確認しろ。
メタループ駆動の場合の例外: requirements/ が存在しない環境（workspace/ec-sample 等）では、progress.txt のストーリー定義を requirements の代替として使用する。
review-conventions.md を読む
.claude/harness/review-memory/review-conventions.md を読み込む(no review conventions yet) を使用する各レビュアーのプロンプトに conventions を埋め込む
## Project Review Conventions
過去のレビューで蓄積されたアンチパターン。新しいコードがこれらに該当しないかチェックしてください。
<review-conventions.md の全文 or "(no review conventions yet)">
3レビュアーを並列ディスパッチする
spec-compliance-reviewer: プロンプトに REQ パス + 対応する REQ の requirements.md 全文 + コード差分 + 関連テストを含めるquality-reviewer: プロンプトにコード差分 + 関連ファイルを含めるsecurity-reviewer: プロンプトにコード差分 + 関連ファイルを含める## Project Review Conventions セクションを各プロンプトに含めるあなたが全指摘を一括収集する
Phase 1 の全指摘を収集した後、以下の処理を実行する。 レビュー自体は Phase 2 の失敗に左右されない。CLI エラーが発生しても Phase 3 に進め。
node .claude/scripts/review-memory.mjs representatives
[{cluster_id, category, pattern, suggestion}, ...].claude/harness/review-memory/review-findings.jsonl が空またはファイルが存在しない場合は空配列Phase 1 で収集した全指摘（3観点分）を並列で curator に渡す
review-memory-curator エージェントを同時ディスパッチするcategory, pattern, suggestion）{"cluster_id": "c-XXX"} を返せ。類似するクラスタがない場合は {"cluster_id": null} を返せ」{"cluster_id": "c-XXX"} または {"cluster_id": null}cluster_id: null（新規クラスタ扱い）としてフォールバック各 curator の出力を集約する
cluster_id が既存（非 null）の指摘 → 該当 cluster_id にマージ対象としてリストアップcluster_id が null の指摘 → 新規クラスタ候補としてリストアップ新規クラスタ候補が複数ある場合、追加の curator 呼び出しでバッチ判定する
review-memory-curator エージェントをディスパッチし、プロンプトに新規クラスタ候補の全指摘を一括で渡す[[指摘A, 指摘B], [指摘C]]）グループ化結果に基づき、各グループに cluster_id を採番して review-findings.jsonl に追記する
add CLI が採番するのは finding の id (rf-NNN) だけで、cluster_id (c-NNN) は採番しない。
グループごとに新規 cluster_id を採番するには --new-cluster フラグを使う。
グループ内の追記手順:
# グループ内の1件目: --new-cluster で新規 cluster_id を自動採番して追記
echo '<finding_json>' | node .claude/scripts/review-memory.mjs add --new-cluster
# → stdout に {"id": "rf-NNN", "cluster_id": "c-NNN"} が返る
# グループ内の2件目以降: 1件目で得た cluster_id を --cluster で指定して追記
echo '<finding_json>' | node .claude/scripts/review-memory.mjs add --cluster c-NNN
--new-cluster と --cluster を両方指定するとエラー（exit 1）cluster_id をそのまま使う（後方互換）注意: 以下の CLI コマンドはコーディネーター（メインセッション）が Bash ツールで実行する。review-memory-curator はクラスタ判定のみを担う。
全指摘について finding JSON を作成する
{
"date": "YYYY-MM-DD",
"project": "<プロジェクト名>",
"reviewer": "spec|quality|security",
"severity": "MUST|SHOULD|CONSIDER",
"category": "...",
"pattern": "...",
"suggestion": "...",
"file": "...",
"cluster_id": "c-XXX"
}
cluster_id は Phase 2-b/2-c で決定した値を使う（新規クラスタ候補は null）各 finding を CLI で追記する（Phase 2-c の手順に従う）
# 既存クラスタにマージする場合（Phase 2-b で cluster_id が決定済み）
echo '<finding_json>' | node .claude/scripts/review-memory.mjs add
# 新規クラスタのグループ内1件目
echo '<finding_json>' | node .claude/scripts/review-memory.mjs add --new-cluster
# 新規クラスタのグループ内2件目以降
echo '<finding_json>' | node .claude/scripts/review-memory.mjs add --cluster c-NNN
昇格処理を実行する
node .claude/scripts/review-memory.mjs promote-all
{"promoted": ["c-001", "c-002"]}昇格されたクラスタがある場合
review-conventions.md から自動的に読み込まれる（Phase 0）code-review の3観点レビュー完了後、以下の2エージェントを並列でディスパッチする:
両エージェントは .claude/harness/observation-log.jsonl に結果を追記する。
メインの3観点レビュー結果とは別管理。observation-log は次セッション開始時に observation-injection ルールで自動注入される。
dispatch 条件:
.claude/ 外のコード）を変更した場合のみ.claude/ 配下）を変更した場合のみMUST 指摘を確認する
修正フェーズ: 依存分析してから implementer をディスパッチする
修正後、MUST 指摘があった観点のみ再レビューする
前提スキル:
必須ルール:
修正時に使うスキル:
次のステップ: