review-gate

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番号>              # PR がある場合
git diff origin/main...HEAD      # PR 前のブランチを見る場合
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 キー・トークン・ 接続文字列等）に関するものである場合:

1. 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 を維持する
2. 前提の自己反証: 「この指摘は前提（例: Secrets Manager 注入が方針）に 依存していないか」「前提が逆（env 管理が方針）なら severity はどう変わるか」 を finding に 1 行で書く。逆転させても severity が変わらないなら判定は 頑健、逆転で下がるなら「前提依存の指摘」であることを明記する。
3. 手順・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）を参照する。このパスは上流リポジトリ基準のため、導入先では 次の順で探索する:

1. 導入先リポジトリの .claude/rules/review-principles.md。 ただし 本 skill が参照する節（例: review-principles.md の §3 Severity 定義）が実在することを確認する。同名でも別内容なら PlanGate の正本ではないため 2 へ進む
2. 無ければ plugin root 配下 <plugin_root>/rules/review-principles.md。 <plugin_root> は Bash で ls "${CLAUDE_PLUGIN_ROOT}/rules/" を実行して展開・確認した 絶対パス（Read ツールは絶対パスを要求し環境変数を展開しないため、${CLAUDE_PLUGIN_ROOT}/... という文字列をそのまま Read しない）。変数が空・未設定ならキャッシュを glob で推測せず 3 へ進む
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 行要約）:
  1. システム状態の可視性 — 処理中・結果・現在地を常時フィードバックしているか
  2. 実世界との一致 — ユーザーの言葉・慣習に沿った表現か（システム内部用語を露出していないか）
  3. ユーザーの主導権と自由 — 取り消し・やり直し・明確な出口があるか
  4. 一貫性と標準 — 同じ意味に同じ表現を使い、プラットフォーム慣習に従っているか
  5. エラー防止 — 誤操作を起こしにくい設計か（確認・制約・安全なデフォルト）
  6. 想起より認知 — 記憶に頼らせず、選択肢・情報を見せているか
  7. 柔軟性と効率 — 熟練者向けショートカットと初心者向け導線が両立しているか
  8. 美的で最小限のデザイン — 不要な情報が主要情報と競合していないか
  9. エラーの認知・診断・回復支援 — 平易なエラーメッセージと解決策を提示しているか
  10. ヘルプとドキュメント — 必要時に文脈に応じたヘルプへ到達できるか
• 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 を新たに参照に加えないこと。