| name | review-gate |
| description | Review Gate を実施し、実装の仕様準拠・品質・セキュリティを 6 観点でレビューする（アーキ設計思想・ロジック正確性・アンチパターン・claim-vs-actual・UI/UX の追加観点レーン付き）。Use when: 実装完了後にレビューをしたい時。「Review Gate を通したい」「コードレビューをして」「実装の品質確認をしたい」「severity を確認したい」。 |
Review Gate
実装後に 6 観点でレビューを行い、critical finding を Completion Gate に伝達する。
Iron Law
NO MERGE WITHOUT TWO-STAGE REVIEW
severity=critical の finding がある場合、fix なしに Completion Gate を通過させない。
Common Rationalizations
| こう思ったら | 現実 |
|---|
| 「テストが通ったからレビュー不要」 | テスト通過はロジック正確性の一部に過ぎない。セキュリティ・仕様準拠は別途確認が必要 |
| 「小さな変更だから critical は出ない」 | 規模に関わらず 6 観点でチェックせよ。1 行の変更でも脆弱性は混入する |
| 「外部レビューを受けたから大丈夫」 | review type の EvidenceItem として記録せよ。記録なき承認は存在しない |
手順
ステップ 1: レビュー対象の差分を取得して finding を収集する
/pg-check は存在しない（TASK-0124 / 2645848, 2026-06-02 の plugin 初回同期適用で
plugin/plangate/commands/pg-check.md が削除され、後継コマンドは無い）。
本節はその代替として、コマンドに依存しない手順を定義する。severity 付き finding を
起こす責務は本 Skill（ステップ 2〜3）が引き継ぐ。旧コマンドを前提とした自動化を
組んでいる場合は、以下の手順に置き換えること。
対象差分を取得する（上から順に該当するものを使う）:
git status
gh pr diff <PR番号>
git diff origin/main...HEAD
git diff && git diff --cached
git diff --stat
取得した差分を精読し、ステップ 2 の 6 観点ごとに finding を起こす。この段階では
severity を付けず、事実（ファイル・行・観察された挙動）だけを列挙する。severity は
ステップ 2 で review-principles.md §3 の定義に従って付与する。
コミット・PR 前のセルフ検査は diff-audit Skill を使う（本 Skill の代わりにはならない）。
diff-audit は「変更を作った本人が PR 前に自分で潰す」段階、本 Skill は「実装完了後の
ゲート判定」段階であり、diff-audit §review-gate との役割分界 のとおり別段階である。
diff-audit の出力を本ステップの入力として持ち込むのは有効だが、それだけで本ステップを
満たしたとは扱わない。
ステップ 2: 6 観点で finding を分類・severity を付与する
ステップ 1 で収集した finding を以下の 6 観点に分類する:
| # | 観点 | チェック内容 |
|---|
| 1 | 仕様準拠 | 受入基準・設計書との一致 |
| 2 | コード品質 | 可読性・命名・構造の明確さ |
| 3 | セキュリティ | 入力バリデーション・認証・認可・機密情報 |
| 4 | パフォーマンス | N+1 クエリ・ループ内 I/O・不要データ取得 |
| 5 | テスト不足 | カバレッジ・エッジケース・重要パスの未テスト |
| 6 | 破壊的変更 | 後方互換性・API 変更・スキーマ変更 |
観点フレームの正本との対応: 本表の 6 観点は本 Skill の運用チェックリストであり、
review-principles.md §2 の 5 観点（可読性・拡張性・パフォーマンス・セキュリティ・
保守性）を「仕様準拠」「破壊的変更」の突合軸込みで実装レビュー向けに再構成したもの。
severity 定義・判定基準は同 §3-4 を正本とする（観点フレームを増やす意図はない）。
ステップ 2.5: secret/config finding の policy-grounding チェック（#731）
背景: 独立した複数レビューエージェント（security / backend / adversarial
等）が「Secrets Manager 注入が正規運用」という同一の前提を共有すると、
adversarial のはずが合意形成で誤りを補強し、false-critical を生む
（#731 観測: .env.production の内部 proxy 用リテラル API キーを 3 エージェント
全員が critical 判定 → 実際は env 管理が意図的なチーム方針だった）。
secret/config のリテラル値は絶対的なアンチパターンではなくプロジェクトの
管理方針に依存する。以下は「セキュリティ」観点で secret/config のリテラル値を
critical/major と判定する前に必ず行う。
セキュリティ観点の finding が secret/config リテラル値（API キー・トークン・
接続文字列等）に関するものである場合:
- policy-grounding チェック: severity を確定する前に、以下いずれかで
プロジェクトの実際の管理方針を検証する。検証せずに一般論（「リテラル値は
常にアンチパターン」）で critical/major を付けない。
docs/ai/secret-management-policy.md（存在すれば、§3 allowlist・§5 判定
手順を正本として参照する）- 同一ファイル内の他キーの記法（他キーもリテラルか、プレースホルダ
${VAR} か）
- taskdef / terraform の
valueFrom、buildspec の .env コピー処理、CI の
secrets 取り扱いなど実装側の注入方針
- 検証できなければ finding に「〜方針を仮定・要確認」と明示した上で
severity を確定する（黙って critical にしない）。severity を一段階
下げるのは env 管理慣習の傍証（同ファイル内の他キーもリテラル等）が
ある場合に限る。傍証ゼロで下げない
- 例外（downgrade 禁止）: 明白に外部サービスのライブ認証情報と
推定されるもの（cloud provider キー・既知の secret scanner 検出
パターン一致等）は、方針が検証できなくても critical を維持する
- 前提の自己反証: 「この指摘は前提（例: Secrets Manager 注入が方針）に
依存していないか」「前提が逆（env 管理が方針）なら severity はどう変わるか」
を finding に 1 行で書く。逆転させても severity が変わらないなら判定は
頑健、逆転で下がるなら「前提依存の指摘」であることを明記する。
- 手順・allowlist の詳細は
docs/ai/secret-management-policy.md
を正本とする（本 Skill は判定手順の呼び出しのみを担い、allowlist データは
持たない）。
ステップ 3: critical finding の有無を判定する
severity=critical が 1 件以上 → Completion Gate をブロックseverity=major が 1 件以上（high-risk / critical Mode）→ 推奨または強制ブロック- それ以外 → PASS
ステップ 4: Review Gate レポートを出力する
以下のフォーマットで出力する（「出力フォーマット」セクション参照）。
ステップ 5: critical finding がある場合は Completion Gate ブロック通知を出力する
[REVIEW GATE] BLOCKED
reason: severity=critical の finding が <N> 件あります。fix 後に再レビューが必要です。
出力フォーマット
Review Gate レポート
Findings（6 観点）
| 観点 | Finding | Severity | 対応 |
|---|
| 仕様準拠 | <finding または「なし」> | <severity> | <対応内容> |
| コード品質 | <finding または「なし」> | <severity> | <対応内容> |
| セキュリティ | <finding または「なし」> | <severity> | <対応内容> |
| パフォーマンス | <finding または「なし」> | <severity> | <対応内容> |
| テスト不足 | <finding または「なし」> | <severity> | <対応内容> |
| 破壊的変更 | <finding または「なし」> | <severity> | <対応内容> |
総合判定
**総合判定**: PASS / BLOCK（critical: N件, major: N件）
→ Completion Gate: PASS / BLOCKED
EvidenceItem（Evidence Ledger への記録）
{
"id": "review-gate-001",
"type": "review",
"reviewer": "review-gate skill",
"outputExcerpt": "critical: 0件, major: N件",
"conclusion": "Review Gate PASS / BLOCKED"
}
Plan Alignment レビュー（#581 要素4）
5 観点・Severity・判定基準（.claude/rules/review-principles.md §2-4。解決順は下記「review-principles.md の参照解決順」）は不変。本ブロックは Plan 正本との突合観点を補う追加レーン（観点数を増やさず C-2 設計妥当性レーン §7-bis と整合）。
review-principles.md の参照解決順（導入先）
本 Skill は severity 定義・判定基準の正本として .claude/rules/review-principles.md
（§2-4 / §7-bis）を参照する。このパスは上流リポジトリ基準のため、導入先では
次の順で探索する:
- 導入先リポジトリの
.claude/rules/review-principles.md。
ただし 本 skill が参照する節（例: review-principles.md の §3 Severity 定義）が実在することを確認する。同名でも別内容なら PlanGate の正本ではないため 2 へ進む
- 無ければ plugin root 配下
<plugin_root>/rules/review-principles.md。
<plugin_root> は Bash で ls "${CLAUDE_PLUGIN_ROOT}/rules/" を実行して展開・確認した
絶対パス（Read ツールは絶対パスを要求し環境変数を展開しないため、${CLAUDE_PLUGIN_ROOT}/...
という文字列をそのまま Read しない）。変数が空・未設定ならキャッシュを glob で推測せず 3 へ進む
- どちらにも無い場合は 「正本
review-principles.md を参照できなかった」と明示する
| 参照 | install.sh --claude 経由 | plugin（Claude marketplace）経由 | Codex 経由 |
|---|
rules/*.md | .claude/rules/ に着地（解決可） | <plugin_root>/rules/ で解決 | 未配置（解決不可 → 手順 3 へ） |
docs/** | コピー対象外（解決不可） | バンドル対象外（解決不可） | 未配置（解決不可） |
install.sh --claude のコピー対象は agents / skills / commands / rules の 4 ディレクトリ
のみ。Codex 経由（install_codex()）は install-plangate-skills.sh を呼ぶだけで skills しか
配置されないため、rules 参照は解決順 1・2 とも成立せず必ず手順 3 に落ちる。
参照解決順（導入先で必ずこの順に探す）: 本 Skill が参照する docs/** は上流リポジトリ基準の相対パスであり、install.sh --claude / plugin（Claude marketplace）/ Codex の 3 経路とも配布対象外（解決不可）。(1) 導入先リポジトリの同名パスを探す → (2)（上のクラス A ブロックの手順 3 に相当）見つからなければ 「正本 <path> を参照できなかった」と明示し、本 Skill 内の記述を代替正本として扱い、推測で内容を補わない。plugin root 配下の探索は docs/** には適用しない: plugin が配布するのは agents / commands / skills / rules 等の定義ディレクトリのみで docs/ を配布対象として認識せず、plugin root 配下に相当する配布物が存在しないため、plugin root 段を置いても必ず空振りする（クラス A の rules 参照が plugin root 配下で解決できるのは rules/ が実際に配布されるからであり、この非対称を docs/** に持ち込まない）。
手順 3 でも Iron Law は緩めない: NO MERGE WITHOUT TWO-STAGE REVIEW と
「severity=critical があれば Completion Gate を通さない」は本 Skill 内で完結する。
ただし本 Skill の 6 観点表は finding の分類軸であり severity 基準を含まないため、
severity 付与の代替正本にはならない。正本未参照時は直下の「severity 定義（4 段階）」を
severity 付与基準として用い、定義を推測で書き換えない。参照できなかった事実は
EvidenceItem の outputExcerpt に併記する。
severity 定義（4 段階）
.claude/rules/review-principles.md §3「Severity定義（4段階）」の写し。正本を解決できた
場合は正本を優先し、齟齬があれば正本が勝つ。
| Severity | 定義 | 例 | マージ影響 |
|---|
| critical | 本番障害・データ不整合・脆弱性 | SQLインジェクション、認可チェック漏れ、データ損失 | ブロッカー |
| major | ロジック誤り・テスト不足・設計違反 | N+1クエリ、レイヤー間依存違反、重要パス未テスト | 修正推奨 |
| minor | 改善提案・命名・コードスタイル | 変数名改善、early return提案、ドキュメント不備 | 任意 |
| info | FYI・将来課題・好みの問題 | 類似パターンの紹介、リファクター候補、補足情報 | 無視可 |
Completion Gate の発火条件（severity=critical が 1 件以上あればブロック）は、この
4 段階定義の critical 行を判定基準とする。
Plan Alignment
- plan.md の Task 要件を満たしているか
- design.md の設計判断から逸脱していないか（逸脱なら理由明示）
- Target Files 外を変更していないか
- Out of Scope に抵触していないか
- 余計な機能を追加していないか（scope creep）
Evidence Alignment
- test-cases.md と Evidence Ledger が対応しているか
- TDD 必須 mode で RED/GREEN 証跡があるか（#584 の tdd_red/green phase。証跡なしは major）
Production Readiness
- エラー処理の具体性 / 後方互換 / セキュリティ・データ損失 / ドキュメント更新
追加観点レーン（#794 / growth-core 由来）
5 観点・severity・判定基準（review-principles.md §2-4）は不変。本節は 5 観点を
実装レビューで深掘りするための運用チェックリスト（既存の 6 観点表・policy-grounding
と同じアドオン位置づけ）。各レーンの finding は 6 観点表のいずれかに分類して severity を付す。
レーン 1: アーキテクチャ設計思想（発火: standard 以上、またはアーキ変更・複数レイヤー変更時）
出典: growth-core architecture-review（Specialist モード 4+1 軸）。5 観点マッピング: 責務分離→拡張性 / 変更容易性・観測可能性・YAGNI→保守性 / セキュリティ境界→セキュリティ。
チェックリスト:
- 責務分離: 関心事が適切に分離されているか。UI 側に業務ロジックが混入していないか。API/サービス層がツールとして独立して機能するか
- 変更容易性: 機能追加・変更が局所化されるか。変更の波及箇所が多すぎないか
- 観測可能性: ログ・メトリクス・トレースで動作を追跡できるか
- セキュリティ境界: 認証・認可・データ分離が適切か。UI ガードレールがない前提で安全か
- YAGNI / 過剰実装: 投機的抽象・未使用の拡張点・過度な汎用化がないか
- MCP / ツール提供設計の場合は追加で: 入力パラメータの自然言語変換しやすさ / レスポンス構造の AI 解釈しやすさ / ツール粒度の適切さ
- 背景思想 1 行: 「ユーザー → AI（自然言語）→ MCP（ツール定義）→ インフラ」の時代は UI ガードレール無し前提で API/ツール層が単独で安全・自己説明的である必要がある
レーン 2: ロジック正確性（発火: code 変更のある全モード）
出典: growth-core reviewer-logic。5 観点マッピング: 可読性・保守性。§5「故障確率で判断」に直結（finding の 6 観点分類ではコード品質が典型）。
チェックリスト:
- ロジック正確性: 条件式の方向・符号・境界値（
< vs <=・off-by-one）/ null・undefined・空配列のハンドリング漏れ / 非同期処理の競合（await 漏れ・Promise 未処理）/ エラーを握り潰す catch
- データフロー: 入力値の変換・加工経路の追跡（意図しない変換）/ 状態変更が他コンポーネントへ与える影響 / 戻り値が呼び出し元で正しく扱われるか
- 境界条件: ゼロ・空・最大値・最小値での挙動 / 型変換によるデータ損失（number→string・float→int）/ ループ終了条件・再帰の基底ケース
- 仕様との整合: 実装がコメント・仕様書・PR 説明と一致しているか / TODO・FIXME の意図せぬ残存
レーン 3: AI 生成コード・アンチパターン（発火: code 変更のある全モード）
出典: growth-core anti-pattern-reviewer。5 観点マッピング: 可読性・保守性。
チェックリスト:
- AI 生成コード特有の罠: 過剰な抽象化・不要なインターフェース層 / 存在しないメソッド・ライブラリ関数の幻覚的参照 / 「動いているように見えるが意図と違う」実装（off-by-one・条件逆転）/ コピーペースト重複（わずかな違いで同じロジックが複数箇所）
- 設計臭: God Object / God Function / 深いネスト・複雑な条件分岐（早期リターンで解消可能なもの）/ hard-coded 定数・マジックナンバー / 呼び出し元が知りすぎている（Law of Demeter 違反）
- 保守性リスク: 変更時に複数箇所を同時修正させる重複（DRY 違反）/ テストが書きにくい実装（副作用混在・依存の隠蔽）/ 命名と実態の乖離
レーン 4: 主張と実態の突合（claim-vs-actual）（発火: code 変更のある全モード。特に「完了」「全置換」「N% 削減」等の主張を含む PR で必須）
出典: growth-core refactor-claim-audit + river-review adversarial-review（Self-Contradiction / Refactor-Claim Audit / Cross-File Leakage）。5 観点マッピング: 保守性（残骸の有無・既存パターン準拠）。finding の 6 観点分類では仕様準拠が典型。verify-then-report 規範の実装レビュー版。
チェックリスト:
- 完了主張の反証: 「全置換」「移行完了」「N% 削減」等の主張を grep 実測（旧 API・旧パターンの残存検索）と独立見積りで検証する。主張を鵜呑みにしない
- Cross-File Leakage: 宣言された変更スコープ外のファイルに変更が漏れていないか（diff --stat と PR 記載の突合。plan の Target Files との突合は Plan Alignment 節が担当 — 突合先が異なる相補チェック）
- Self-Contradiction: PR 説明・コミットメッセージ・コメント・docs の間、および同一文書内での自己矛盾
- 不採用・反証の記録は仕様引用または実測コマンド+結果を必須とする（推測のみでの棄却・採用をしない）
レーン 5: UI/UX・アクセシビリティ（発火: UI 変更を含む全モード / #797）
出典: growth-core ui-ux-review（Nielsen 10 + WCAG の汎用部のみ。LP・CVR 等のドメイン固有評価軸は不採用）+ W3C WCAG 2.2。5 観点マッピング: UI 一貫性→可読性 / アクセシビリティ・レスポンシブ→保守性（finding の 6 観点分類ではコード品質・仕様準拠が典型 — レーン 2/4 と同形式）。
発火条件（機械可読ヒューリスティック）: 差分に UI 系パス・拡張子を 1 つでも含む場合に発火する。例示リスト（プロジェクトの UI 層構成に応じて読み替える）:
- 拡張子:
*.css / *.scss / *.vue / *.tsx / *.jsx / *.svelte / *.blade.php / *.erb / *.html
- パス:
components/** / views/** / templates/** / pages/** 等
安全側規則: UI 変更か否かが曖昧な場合は発火側に倒す（mode-classification.md 変更種別軸の「境界が曖昧なら上位種別」と同型）。
入力可用性条項: スクリーンショット / プレビュー URL / Figma 等の視覚入力がレビュー入力に無い場合、黙ってスキップしない。次のいずれかを行う: (a) 取得手順を提示する（ローカル起動 + スクリーンショット採取、Playwright 等）、(b) docs/ai/external-reviewer-interface.md §10 と同型の unavailable 記録（理由・代替検証観点・未充足リスク）を finding に残す。
チェックリスト（要約 — 各項目の個別解説・Pass/Fail 判定方法・worked example は references/ui-ux-lane.md）:
- Nielsen 10 ヒューリスティクス（項目名 + 1 行要約）:
- システム状態の可視性 — 処理中・結果・現在地を常時フィードバックしているか
- 実世界との一致 — ユーザーの言葉・慣習に沿った表現か（システム内部用語を露出していないか）
- ユーザーの主導権と自由 — 取り消し・やり直し・明確な出口があるか
- 一貫性と標準 — 同じ意味に同じ表現を使い、プラットフォーム慣習に従っているか
- エラー防止 — 誤操作を起こしにくい設計か（確認・制約・安全なデフォルト）
- 想起より認知 — 記憶に頼らせず、選択肢・情報を見せているか
- 柔軟性と効率 — 熟練者向けショートカットと初心者向け導線が両立しているか
- 美的で最小限のデザイン — 不要な情報が主要情報と競合していないか
- エラーの認知・診断・回復支援 — 平易なエラーメッセージと解決策を提示しているか
- ヘルプとドキュメント — 必要時に文脈に応じたヘルプへ到達できるか
- WCAG 必須（基本 5 点）: コントラスト比 4.5:1 以上（通常テキスト）/ 画像の alt / フォーカス可視 / キーボードのみで全操作可能 / フォーム入力へのラベル関連付け
- WCAG 2.2 新基準（A/AA の 6 つ）:
- 2.4.11 Focus Not Obscured (AA) — フォーカスした要素が固定ヘッダー等に完全に隠れない
- 2.5.7 Dragging Movements (AA) — ドラッグ操作に単純ポインタ操作（クリック/タップ）の代替がある
- 2.5.8 Target Size (AA) — タップターゲットが 24×24 CSS px 以上（間隔で補える例外あり）
- 3.3.8 Accessible Authentication (AA) — 認証が記憶・転記等の認知テストに依存しない
- 3.2.6 Consistent Help (A) — ヘルプ手段が複数ページで一貫した位置にある
- 3.3.7 Redundant Entry (A) — 同一プロセス内で同じ情報の再入力を求めない
- レスポンシブ確認: 主要ブレークポイント（最低 PC/SP 2 点）でレイアウト崩れ・横スクロール・要素の重なりがない
UI 変更時の V-1 evidence 規約（PASS でも visual evidence 必須）は acceptance-review Skill の「UI 変更時の visual evidence 規約」を参照（本レーンと同一の発火ヒューリスティックを共有する兄弟規約）。
関連
- Rule:
mode-classification.md（Mode 別フェーズ適用マトリクス・発火条件の正本）
- Skill:
diff-audit（コミット・PR 前のセルフ検査。本 Skill とは別段階）
- Skill:
evidence-ledger（EvidenceItem 記録手順）
- Rule:
review-principles.md（レビューの姿勢・禁止事項・False-positive ガード）
- Doc:
docs/ai/secret-management-policy.md（secret/config policy-grounding の allowlist・判定手順正本 / #731）
旧 plugin/plangate/commands/pg-check.md は削除済み（TASK-0124 / 2645848,
2026-06-02 の plugin 初回同期適用）で後継コマンドは無い。finding 収集の手順は
本 Skill §手順 ステップ 1 が引き継いだ。/pg-check を新たに参照に加えないこと。
