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）が引き継ぐ。旧コマンドを前提とした自動化を
> 組んでいる場合は、以下の手順に置き換えること。

対象差分を取得する（上から順に該当するものを使う）:

```bash
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 ブロック通知を出力する

```text
[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\> | \<対応内容\> |

#### 総合判定

```text
**総合判定**: PASS / BLOCK（critical: N件, major: N件）

→ Completion Gate: PASS / BLOCKED
```

#### EvidenceItem（Evidence Ledger への記録）

```json
{
  "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`](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` を新たに参照に加えないこと。