Immutable. This exact content is served forever at /api/v1/blob/940083a84ef6871a.
--- name: river-review-discipline description: AI 駆動開発のレビュー品質を安定化させるレビュー規律。レビュー対象を分類し、要件・設計・差分・検証・報告を分けて見て、根拠に基づき approved / needs_revision / blocked / rejected を明示し、未検証事項と残リスクを隠さず memory に残す。「レビューして」「PR レビュー」「仕様/設計/差分/検証/報告をレビュー」「セキュリティ影響/データ影響を確認」「完了報告を検証」「/compact 前にレビュー記憶を作る」ときに使う。 allowed-tools: Read, Grep, Glob, Bash --- # RiverReview Discipline AI が「実装したつもり」「確認したつもり」「問題ないはず」で完了報告することを防ぐレビュー規律。 Fable 5 の検証習慣・レビュー観点・リスク発見・差分読解・次アクション決定を、日常モデルでも 継承できる運用ルールとして外部化したもの。 このスキルは RiverReview の既存資産の**上位の運用規律**であり、既存を置き換えない。 判断語彙・観点・記録は既存へ橋渡しする（下表・各節の「参照」を見よ）。 ## When to use - PR / 差分 / 仕様 / 設計 / 実装計画 / テスト / 検証レポート / 完了報告をレビューするとき - セキュリティ影響・データ影響・破壊的変更を含む変更を判断するとき - サブエージェントにレビューを分担させるか判断するとき - `/compact` や要約でレビュー判断が失われそうなとき（memory 作成） ## When not to use - 実装そのものを書くとき（本スキルはレビュー規律であって実装手順ではない） - 語句・体裁のみの typo 修正（分類 `documentation`・low リスクで軽く通す） - レビュー対象が単一・小さく、既に十分な検証証跡があるとき（過剰適用しない） ## 既存 RiverReview 資産へのマッピング（重複させない） | 本スキルの概念 | 既存 RiverReview 資産 | | ---------------- | ------------------------------------------------------------------------------- | | レビュー観点 | `docs/review/viewpoints.md` / `pages/reference/review-policy.md`（SSoT） | | 重要度 | `docs/review/output-format.md` の `critical` / `major` / `minor` / `info` | | 差分外の盲点発見 | `skills/agent-skills/adversarial-review`, `skills/upstream/pre-mortem` | | 要件の未決明示 | `skills/upstream/requirements-acceptance` | | 逸脱記録 | PR テンプレの Deviations 節 + `plangate-exec-conformance` の `design-deviation` | | memory | `docs/CONTINUITY.md`（plan 継続台帳） | | 機械判定（gate） | `src/lib/gate-decision.mjs` の `deriveGateDecision`（下表で対応づけ） | ### レビュー工程の判断 ↔ gateDecision ↔ リスク階層 本スキルの `approved / needs_revision / blocked / rejected` は**人間/エージェントのレビュー工程の判断**。 RiverReview の機械 gate（host 側導出）とは責務が異なるが、次のように対応づく。 | レビュー判断 | gateDecision | リスク階層 | 意味 | | -------------- | -------------------------- | ----------- | ------------------------------------------ | | approved | GO / GO_WITH_OBSERVATION | 原っぱ / 丘 | 続行可。観測付き続行を含む | | needs_revision | NO_GO（BLOCKING_FINDINGS） | — | 直せば通る。修正して再レビュー | | blocked | ESCALATE | 崖 | 人間承認・追加情報・検証不能。止める | | rejected | NO_GO（方針却下） | — | 要件不適合・設計矛盾・より安全な代替案あり | ## Core principles 1. **レビュー対象を最初に分類する**（下記 Classification）。分類前にレビューを始めない。 2. **要件・設計・差分・検証・報告を混同しない**。混ぜると観点が漏れる。 3. **「問題なさそう」で通さない**。approve する場合も**確認した根拠**を添える。 4. **変更されなかった重要箇所も見る**。差分外の互換性・整合性・盲点（pre-mortem / adversarial-review）。 5. **既存設計との整合性を最優先で確認する**（`viewpoints.md`・ADR・既存パターン）。 6. **実装差分が要求を満たすかを検証する**。差分の正しさと要件充足は別。 7. **テストは「ある」ではなく「適切な失敗を検知できる」かを見る**。 8. **未検証事項を隠さない**。「実装したこと / 確認できたこと / できていないこと / 推測 / 人間確認要」を分ける。 9. **破壊的変更・セキュリティ影響・データ影響は強制的に高リスク扱い**（下記 Risk）。 10. **判断は approved / needs_revision / blocked / rejected で明示**する。 11. **却下した案・懸念・残リスクを memory に残す**（`review-memory.md`）。 12. **次の一手は、最もリスクが高い未確認事項から決める**。 ## Review target classification レビュー前に対象を1つ以上に分類する。分類ごとに「見る観点」と「見なくてよい観点」を持つ。 | 分類 | 見る | 見なくてよい | | --------------------------- | ------------------------------------------------------------ | ---------------------------- | | `requirements` | 課題の明確さ・スコープ・受入条件・前提・曖昧さ | 実装詳細・コードスタイル | | `design` | 既存整合・責務分離・データフロー・エラー処理・拡張性 | 具体的な変数名・行単位の実装 | | `implementation_plan` | 変更対象・影響範囲・検証手順・順序・ロールバック | 最終コードの細部 | | `diff` | 要件充足・計画外変更・既存挙動破壊・テスト・安全性 | 未変更ファイルの一般批評 | | `test` | 適切な失敗検知・境界・回帰・偽陽性/偽陰性 | 本番実装の設計論 | | `verification_report` | 実行/未実行の検証・証跡・残リスク・完了判定の妥当性 | コード美観 | | `report` | 実施内容の具体性・変更ファイルの明示・証跡の裏取り・残リスク | コードスタイル・美観 | | `documentation` | 正確性・実行例の動作・リンク・SSoT 整合 | 実装内部 | | `release_readiness` | CI・移行・ロールバック・監視・段階公開 | 個別行レビュー | | `security_sensitive_change` | 認証認可・秘密情報・信頼境界・入力検証（強制 high 以上） | — | | `data_sensitive_change` | データ破壊・不可逆・移行安全性・整合性（強制 high 以上） | — | | `unknown` | まず分類を確定させる。不明なまま進めない | — | 各対象の詳細チェックリストは `templates/` の各テンプレを使う。 ## Requirements review（要点） ユーザー要求との整合 / 解決課題の明確さ / スコープ / Non-goals / 成功条件 / 受入条件 / エッジケース / 依存 / 制約 / 未定義の前提 / 仕様の曖昧さ / 実装前に確認すべき質問。 → `templates/requirements-review-template.md`。既存 `requirements-acceptance` skill と併用。 ## Design review（要点） 既存設計との整合 / 責務分離 / データフロー / エラー処理 / セキュリティ / パフォーマンス / テスト容易性 / 保守性 / 拡張性 / 過剰設計 / 依存追加の妥当性 / 代替案 / ロールバック容易性。 → `templates/design-review-template.md`。盲点は `pre-mortem` / `adversarial-review` を併用。 ## Diff review（要点） 要件充足 / 計画外変更の有無 / 既存挙動破壊 / 命名・責務・構造の整合 / エラー処理明示 / 不要依存の追加 / テスト追加更新 / テストの失敗検知力 / セキュリティ / データ破壊・不可逆 / 秘密情報・PII・認証情報の混入 / パフォーマンス劣化 / ログ・監視・運用影響 / ドキュメント更新要否。 → `templates/diff-review-template.md`。**差分に存在しないコードへの推測指摘は禁止**（`.claude/rules/review-core.md`）。 ## Verification review（要点） 実行コマンド / 実行結果 / 成功 / 失敗 / スキップ / 未実行 / 手動確認 / 再現手順 / 証跡 / 残リスク / 完了判定の妥当性。次を必ず**分けて**書く: 実装したこと / 確認できたこと / 確認できていないこと / 推測していること / 人間確認が必要なこと。 → `templates/verification-review-template.md`。 ## Report review（要点） 実施内容の具体性 / 変更ファイルの明示 / 検証結果の観測可能性 / 未検証事項の隠蔽有無 / 残リスクの明示 / 判断が要る点の明示 / 次アクションの妥当性 / 「完了」に十分な証拠があるか。 **背景**: 完了報告は捏造されうる（もっともらしい PR 番号・テスト数・コマンド出力）。報告の質は実行の証拠ではない。 → `templates/report-review-template.md`。 ## Decision rules - **approved**: 要件適合 + 既存設計整合 + 重大リスクなし + 必要な検証が成功 + 未検証事項が許容範囲で**明示**されている。**根拠を添える**。 - **needs_revision**: 方向性は正しく、修正すれば通せる。不足検証・説明、軽〜中の設計懸念がある。 - **blocked**: 重要情報の不足 / 人間承認が必要 / 本番・データ・認証・課金・セキュリティ影響が未確認 / 検証不能 / 外部仕様・料金・規約の確認要。→ ESCALATE（崖）。 - **rejected**: 要件不適合 / 既存設計と大きく矛盾 / リスク対効果が低い / 過剰実装 / セキュリティ・データ破壊・運用リスクが高い / より安全で安価な代替案が明確。 ## Risk classification `low` / `medium` / `high` / `critical`。以下は**強制的に high 以上**（迷ったら critical 寄り）: データ削除 / DB schema 変更 / 認証・認可変更 / 課金・請求変更 / 外部 API 変更 / 本番設定変更 / CI/CD 変更 / セキュリティ設定変更 / 依存の大幅追加 / 大規模リファクタ / irreversible な変更 / PII・secret・credential の取り扱い / 監視・ログ・アラートへの影響。 fail-safe: **不明・未決・malformed は安全側（high / blocked / ESCALATE）へ倒す**。GO 方向に倒さない。 ## Subagent review rules **使う条件**: 複数観点の分離が要る / セキュリティ・設計・テストを分けたい / 差分が大きい / 外部仕様調査が要る / 重要判断のバイアスを減らしたい。 **使わない条件**: 小さな typo / 単純な docs 修正 / 差分が小さく観点が単一 / 起動コストの方が高い / 既に十分な検証証跡がある。→ **サブエージェント利用を目的化しない**。 使う場合は各サブエージェントに明示する: **Role / Review target / Context / Expected output / Decision criteria / What not to review**。返ってきた指摘は**鵜呑みにせず**、レビュー主体が差分・ ソースで検証する（誤指摘はある）。 ## Memory rules `/compact` 後に失われると困る判断を `review-memory.md`（または `docs/CONTINUITY.md`）に残す: 採用したレビュー判断 / 却下した案と却下理由 / 既存設計上の制約 / 繰り返しそうなレビュー漏れ / 重要な検証コマンド / 未解決リスク / 次回見るべきファイル / 次の一手。 ## Final report rules レビュー報告には必ず含める: **Review target / Decision / Risk level / Findings / Required changes / Verification status / Unverified items / Remaining risks / Recommended next action**。 「問題なし」と言う場合は**確認した根拠**を添える。 ## このバンドルのファイル - `river-review-loop.md` — 標準ループ（Intake→Classify→Review→Risk→Decision→Verify→Remember→Next Action） - `review-memory.md` — セッション跨ぎの memory テンプレ - `templates/requirements-review-template.md` ほか各レビューテンプレ - `anti-patterns.md` — 避けるべきレビューの型 - `usage-prompts.md` — Claude Code 用の短い使用例プロンプト