Review

Step 1: Pre-Flight Check

レビュー開始前に必ず確認する。準備不足でレビューを開始すると、表面的な指摘に終始する。

必須確認事項

レビュー種別の判定

レビュー対象は？
  ├── 提案書・設計書・仕様書 → Step 2: ドキュメントレビュー
  ├── ソースコード           → Step 3: 技術仕様レビュー
  ├── PR / コミット          → Step 3 + Step 4: 挑戦的レビュー
  └── 複合（ドキュメント+コード）→ Step 2 + Step 3

チェックリスト:

品質ガードレール

• 個人の好みに基づくコーディングスタイル指摘をレビューコメントに含めてはならない
• 修正提案なしの否定的コメントのみを残さないこと

品質基準:

• レビューコメント数 最大 50 件/PR

• レビュー応答時間 閾値: 24 時間以内

• 20_notes/ を読み、仕様を完全に理解した

• レビュー対象の成果物を読み、内容の意図を理解した

• 40_decision_log/ を確認し、過去の設計判断を理解した

• 品質基準を確認した

• レビュー種別を判定した

Step 2: ドキュメントレビュー

提案書・設計書・仕様書の品質を 4 つの観点で検証する。

2a: 要件カバレッジ

要件定義の全項目がドキュメントで漏れなく回答されているか。

2b: 章間整合性

ドキュメントの各章が互いに矛盾していないか。

2c: 数値・データの妥当性

2d: 可読性と説得力

チェックリスト:

• 2a: 全要件に対応する章が存在するか
• 2b: 各章の数値・前提が相互に矛盾していないか
• 2c: 積算根拠・前提条件が明記されているか
• 2d: 読者が意図通りに理解できる構成か
• 用語が 20_notes/glossary.md に準拠しているか

Step 3: 技術仕様レビュー

ソースコード・技術設計を 6 つの観点で検証する。

3a: Semantic Drift（仕様との意味的乖離）

実装が notes の仕様から逸脱していないか。

検証方法: 20_notes/domain-model.md のエンティティ定義を読み、実装コード（src/models/ 等）と照合する。

3b: Accounting Integrity（会計・数値整合性）

3c: Edge Case Attack（境界値攻撃）

3d: Privacy Violation（プライバシー侵害）

3e: Performance & Scalability

3g: State Alignment（ペルソナ心理状態の整合性）

ペルソナの State Dimensions（Belief/Value/Stance/Emotion/Communication）が、 ストーリーの受入基準・テストデータ・UX 設計に一貫して反映されているか検証する。

State Alignment 評価ルーブリック:

適用条件: State Dimensions が 20_notes/ または story-map 成果物に定義されている場合に適用。 未定義の場合は Info レベルで「State Dimensions の定義を推奨」と指摘する。

3f: Test Coverage

各基準の詳細なコード例と指摘パターンは references/technical-review-examples.md を参照。

チェックリスト:

• 3a: 仕様との乖離がないか
• 3b: 数値処理が正確か
• 3c: 境界値で破綻しないか
• 3d: 機密情報の漏洩がないか
• 3e: パフォーマンス問題がないか
• 3f: テストカバレッジが十分か

Step 4: 挑戦的レビューモード（Challenging Review）

レビュー完了後、以下のセルフチャレンジを実施して品質を一段引き上げる。

チャレンジパターン

挑戦的レビューの手順

1. 通常レビュー完了: Step 2 or Step 3 の全チェック項目をパス
2. チャレンジ選択: レビュー対象に最適なチャレンジパターンを 1-2 つ選定
3. チャレンジ実行: 選定したパターンでセルフレビューを実施
4. 追加指摘: チャレンジで発見された問題を既存レポートに追加
5. 最終判定: 全指摘を統合して最終的な承認/却下を決定

原則: 挑戦的レビューは全レビューの仕上げフェーズとして推奨。特に PR レビュー時には必須。

チェックリスト:

• 通常レビュー（Step 2/3）が完了しているか
• 適切なチャレンジパターンを選定したか
• チャレンジで追加の問題が発見されたか
• 発見された問題を既存レポートに統合したか

Step 5: レポート出力と承認判定

レポート構造

# レビューレポート

## メタ情報
- 案件名: <案件名>
- レビュー対象: <ファイル名 or PR 番号>
- レビュー種別: ドキュメント / 技術仕様 / 複合
- レビュー日: YYYY-MM-DD
- レビュー基準: Step 2(2a-2d) / Step 3(3a-3f) / 挑戦的レビュー

## 結果サマリー

| 深刻度 | 件数 |
|:---|---:|
| Critical | X |
| Major | X |
| Minor | X |
| Info | X |

## 総合判定: Approved / Conditional / Rejected

## 指摘一覧

| # | 深刻度 | 箇所 | 問題 | 影響 | 修正案 |
|---:|:---|:---|:---|:---|:---|
| 1 | Critical | ... | ... | ... | ... |

## 推奨アクション
1. ...

## 挑戦的レビュー結果（実施した場合）

承認条件

成果物が完璧であると論理的に証明できない限り、承認を与えてはならない。

指摘のレベル分け

レビュー出力 Slop 防止チェック（Distributional Convergence 対策）

レビュー結果が定型文の羅列に収束すると、レビュー対象固有の本質的な問題を見逃し、レビューが「儀式」に退化する。レビューの価値は、対象に踏み込んだ固有の洞察にある。

核心原則: レビューは対象の「鏡」であり、レビューアの「定型文置き場」ではない — レビューレポートだけを読んで、レビュー対象が何であったか特定できるか？「別の成果物のレビューに差し替えても違和感がないか？」→ 違和感がないならレビュー出力 Slop である。

チェックリスト:

• レポートの全セクションが記入されているか
• 各指摘に深刻度・箇所・影響・修正案が含まれているか
• 総合判定が承認条件に基づいているか
• 40_decision_log/ にレビュー判断を記録したか
• Conditional/Rejected の場合、再レビューの条件を明示したか
• レビュー出力 Slop チェック（RV-1〜RV-6）に 2 つ以上該当しない
• 出力がドメイン固有の要素を含み、汎用テンプレートに見えない

Examples

Example 1: ドキュメントの要件カバレッジレビュー

「review スキルで、ドキュメントを要件カバレッジの観点からレビューして」

→ Step 1: 20_notes/ を精読、レビュー種別 = ドキュメントレビュー
→ Step 2(2a): 要件リスト vs 目次を照合。全 25 要件中 23 要件カバー、2 要件漏れ（Critical）
→ Step 2(2d): 漏れ要件の代替案が記載されていないことを確認（Major）
→ Step 5: Rejected — Critical 2 件。漏れ要件の章追加を指示

Example 2: 章間整合性と数値妥当性のレビュー

「review スキルで、ドキュメントの章間整合性と数値の妥当性をチェックして」

→ Step 1: 20_notes/ + 30_proposal/ を精読
→ Step 2(2b): スケジュール章の工数 120 人月 vs 見積章の合計 115 人月 → 不一致（Critical）
→ Step 2(2c): リスクバッファ 5% — 低すぎる（Major）
→ Step 5: Rejected — Critical 1 件。工数の不一致を解消し再提出を指示

Example 3: ソースコードの仕様乖離チェック

「review スキルで、ソースコードを notes との整合性の観点からレビューして」

→ Step 1: 20_notes/domain-model.md を精読、レビュー種別 = 技術仕様レビュー
→ Step 3(3a): User エンティティの email 属性が UNIQUE 制約なし（Major）
→ Step 3(3c): age フィールドの負数チェック漏れ（Major）
→ Step 3(3d): ログに email をプレーンテキストで出力（Critical）
→ Step 5: Rejected — Critical 1 件。PII ログ出力の修正を最優先指示

Example 4: 挑戦的レビュー（PR 品質の最終検証）

「この PR の変更点を grill して、テストに通るまで PR を作らないで」

→ Step 1: 対象ブランチの差分を把握
→ Step 3: 技術仕様レビュー（3a-3f）を適用
→ Step 4: `git diff main...HEAD` で振る舞い差分を検証
→ Step 4: `Prove to me this works` で動作保証の根拠を確認
→ Step 5: Critical/Major 指摘がゼロになるまで修正→再検証を反復
→ 結果: Approved — 3 回の修正反復で全 Critical/Major を解消

Example 5: CI テスト失敗の根因分析レビュー

「CI テストが 3 件落ちています。レビューして修正方針を示してください」

→ Step 1: CI ログから失敗テストを特定（test_auth, test_payment, test_report）
→ Step 3(3a): 仕様乖離がないか確認 — リファクタリングでインターフェース変更を検出
→ Step 3(3c): 境界値・環境依存（タイムゾーン）の問題を検出
→ Step 3(3f): テスト自体の品質を検証 — test_report は偽陽性と判定
→ Step 5: 修正方針をレベル別に提示（Critical: auth 即修正 / Major: payment / Info: report）

Example 6: API ドキュメントのクロスレビュー

「API 仕様書と実装コードのクロスレビューをして」

→ Step 1: 20_notes/api-spec.md と src/routes/ を照合準備
→ Step 3(3a): エンドポイント定義の一致確認（HTTP メソッド、パス、パラメータ）
→ Step 2(2c): レスポンスのステータスコードとエラーメッセージの妥当性
→ Step 3(3d): レスポンスに不要な内部情報（stack trace、DB ID）が漏洩していないか
→ Step 5: 不一致リストをテーブル形式で提示。Conditional — Major 2 件

Troubleshooting

References

Structured Output Format

レビュー結果を 40_decision_log/ に蓄積するための JSON 出力形式を定義する。

JSON Schema

{
  "review_id": "REV-YYYY-MM-DD-NNN",
  "date": "YYYY-MM-DD",
  "target": {
    "file": "path/to/file",
    "type": "document | code | design | proposal"
  },
  "reviewer": "Claude Opus 4.6",
  "summary": {
    "overall_score": "S | A | B | C | D",
    "critical_count": 0,
    "major_count": 0,
    "minor_count": 0,
    "suggestion_count": 0
  },
  "findings": [
    {
      "id": "F-001",
      "severity": "critical | major | minor | suggestion",
      "category": "A-1 | A-2 | A-3 | A-4 | B-1 | B-2 | B-3 | B-4 | B-5 | B-6 | B-7",
      "location": "section or line reference",
      "finding": "description of the issue",
      "recommendation": "suggested fix",
      "resolved": false
    }
  ],
  "metrics": {
    "coverage": 0.0,
    "consistency": 0.0,
    "accuracy": 0.0,
    "readability": 0.0
  }
}

Usage

レビュー完了後、以下のファイルに保存する:

• パス: 40_decision_log/REV-YYYY-MM-DD-NNN.json
• 命名規則: REV- + 日付 + - + 連番（001〜999）

アンチパターン検出

このスキルの出力品質を検証し、AI Decay（品質劣化）を防止するためのアンチパターン検出リスト。各項目は品質劣化パターンの検出条件を定義し、不合格時は対応する対策（修正ガイドライン）に従って改善する。

• レビュー指摘が Critical/Warning/Suggestion の重要度で分類されているか
• 問題点だけでなく具体的な修正案がセットで提示されているか
• レビュー対象のドメイン固有の基準（コーディング規約・設計原則等）に基づいているか（汎用的な「改善の余地あり」を排除）
• 良い点の指摘が含まれているか（問題点のみの一方的なレビューになっていないか）
• レビュー結果の JSON 出力が REV-YYYY-MM-DD-NNN 形式で保存可能な構造か
• 数値データの整合性チェックが含まれているか（data-validation との連携を確認）

Related Skills