設計哲学

River Review は、チームの暗黙知を versioned / repo-owned な Skill（Skill Registry）へ落とし込み、共有資産として再利用することを基盤としている。その基盤の上に、AI エージェントのレビュー能力向上に資する capability pack、共有資産としてのレビュースキル、観点別レビュアーを並列実行する review team という 3 主軸が乗る。以下の原則は、この 3 主軸を支える設計判断をまとめている。

River Review は、チームの速度を落とすことなく、タイムリーでフェーズを意識したフィードバックを提供するために構築されている。

• Flow-first: すべてのチェックは、どのフェーズに属するか、そしてなぜそのフェーズなのかを明記すべきである。
• Small, testable steps: 明確な合格シグナルを持つ、狭くスコープされたスキルを好む。
• Schema-driven: /schemas/skill.schema.json はすべてのスキルの契約であり、単一の真実のソースであり続けるべきである。
• Empathetic tone: 発見事項はアクション可能で建設的であるべきであり、フレンドリーな River Review ブランドにマッチさせるべきである。
• Evidence-based: ガイダンスを、推奨事項を証明するコマンドやリンクに結びつける。
• Context-aware: LLM に渡すコンテキストを体系的に設計する。スキル・差分・メモリの選択と段階的開示により、限られた Context Budget の中でレビュー品質を最大化する。

Non-Goals

River Review は以下を目指していない:

• 汎用 AI エージェントフレームワーク: コードレビューに特化した context engineering framework であり、汎用タスク実行基盤ではない。review team も、1 つの orchestrator が観点別レビュアーロールによる並列レビューの結果を connected-components でマージする仕組みであり、完全に自律した独立エージェント群ではない。
• 人間のレビュー判断の代替: AI はレビュー観点の提示と検証を支援する。findings と verdict はあくまで判定素材であり、GO / NO-GO・反復・停止の判断は caller や人間（HITL）の責務である。自動承認や自動マージは主張しない。
• コード自動修正: 問題の発見と指摘を行うが、コード変換や自動修正は行わない。

進化の方向性：リスク階層型の人間監督

River Review は、変更のリスクを 3 階層へ分け、階層ごとに人間監督の重さが変わります。まず崖（cliff）はリスクの高い変更で、人間承認が必須の HITL を温存します。その上で、丘（hill）には期限付き観測を課し、原っぱ（field）は自律収束させて事後に監査します。ねらいは、希少な人間の注意を崖へ再配分することにあります。監督そのものを減らす意図ではありません。詳細は ADR-003（docs/adr/003-risk-tiered-human-supervision.md）を参照してください。

上記 Non-Goals の「人間のレビュー判断の代替」は、恒久的な制約ではなく現時点の到達点です。人間にしか判断できないとされる領域（要求とのズレ、設計判断の妥当性、リスクの重み付け、暗黙の前提）も、判断に必要なコンテキストを正しく抽出・整形して渡せれば、AI レビューが検証可能な範囲は広がります。

• 崖（cliff / ESCALATE）: リスクの高い変更では人間承認が必須で、HITL を温存する。ここでの最終判断は常に人間が下す。
• 丘（hill / GO_WITH_OBSERVATION）: 継続は許すが、期限付きの観測を課す。期限を過ぎたら未レビュー扱いへ戻す。
• 原っぱ（field / GO）: 収束したクリーンな変更は自律継続を許し、run-record や digest で事後に監査する。
• 精度向上の前提: 自動化範囲の拡大は、検証（finding verification）とフィードバック反映（improvement-loop）の裏付けに限る。consensusLevel や検証実績が積み上がった観点から広げ、裏付けのない領域を先行させない。

ループ監督の設計原理としては、人間の役割を「都度判断する」から「ループを監督し必要な時だけ介入する」（Human-on-the-Loop）へ寄せます。ただし看板はあくまでリスク階層型の人間監督であり、崖の人間承認を緩めません。