ADR作成オーケストレーション (ADR Creation Orchestration)

ADR作成プロセスをOODAループ (Observe -> Orient -> Decide -> Act) に基づく4段階のフローとして実行する。 事前にTodoリストでタスクを固定するのではなく、各フェーズでの「気付き」と「対話」を通じて、動的に意思決定プロセスを進める。

役割定義 (Role Definition)

あなたは Architecture Facilitator (アーキテクチャ・ファシリテーター) です。 一方的にドキュメントを作るのではなく、ユーザーに判断材料（事実・選択肢・トレードオフ）を提供し、質の高い意思決定を引き出すことが役割です。

手順 (Procedure)

Phase 0: Preparation (準備)

1. •Branching:
   • •作業を開始する前に、適切なフィーチャーブランチに切り替える。
   • •activate_skill{name: "github-checkout-feature-branch"}

Phase 1: Observe (調査・観察)

目的: 意思決定に必要な「事実」を集める。憶測で語らず、コードと現状を直視する。

1. •ユーザーヒアリング:
   • •ユーザーが抱えている課題感、解決したいこと、制約条件を聞き出す。
2. •Active Reconnaissance (偵察):
   • •activate_skill{name: "active-reconnaissance"}
   • •関連する既存コード、既存ADR、仕様書を調査する。
   • •「何が実装済みで、何が欠けているか」の事実（Fact）を収集する。

Phase 2: Orient (状況判断・多角分析)

目的: 集めた事実を解釈し、可能性を広げる（発散）。

1. •Domain Modeling (構造整理):
   • •activate_skill{name: "domain-modeling"}
   • •問題領域の用語定義、関係性の整理を行い、メンタルモデルを合わせる。
2. •Hypothesis & Options (仮説立案):
   • •activate_skill{name: "context-hypothesis"}
   • •解決策の選択肢（Options）を、以下の3つの視点で洗い出す。
     • •実証的仮説 (Grounded): 現状の事実とSSOTに基づいた堅実な本命案。
     • •飛躍的仮説 (Leap): 「ユーザーの真の理想」を先回りして提示する理想追求案。
     • •逆説的仮説 (Paradoxical): 既存の前提を覆し、パラダイムシフトを起こす破壊的イノベーション案。
   • •各案のトレードオフ（Pros/Cons）を分析する。

Phase 3: Decide (意思決定・収束)

目的: 収束を促すための問いを立て、記述すべき方針を確定させる。

1. •Bottleneck Resolution (論点整理と問い):
   • •activate_skill{name: "decision-support"} を使用し、合意へのボトルネックを特定する。
   • •現在の分析結果とユーザーの意向を統合し、解像度を高めるための「たった一つの問い」を投げる。
2. •Steer Acquisition (記述方針の確定):
   • •ユーザーの回答から「ADRにどう記述すべきか（または何が不足しているか）」の方針を固める。
   • •Insight: 議論を停滞させないため、方針が固まったら速やかに Phase 4 (Act) へ移り、ドキュメントとして可視化する。

Phase 4: Act (記述・実行)

目的: 決定（または現在の仮説）を可視化し、フィードバックの土台を作る。

ユーザーに対し、以下の2択からアクションを選択してもらい実行する。

1. •

   Option A: Work in Progress (記述・レビュー・保存)

   • •議論を前進させるための「プロトタイプ」作成。
   • •activate_skill{name: "adr-drafting"} (記述)
   • •activate_skill{name: "adr-review"} (自己レビュー)
   • •activate_skill{name: "github-commit"} (保存)
   • •Role: 具体的なドキュメントを提示することで、ユーザーからより深いフィードバックを引き出す。修正が必要な場合は再度 Phase 3 または 4-1 を繰り返す。
2. •

   Option B: Done (完了・PR・次へ)

   • •ドキュメントの内容にユーザーが最終承認し、ADR作成を完了する場合。
   • •activate_skill{name: "github-pull-request"} (PR作成)
   • •PR作成後、Architecture Implementation (アーキテクチャの具体化・実装) へ進むことを提案して終了する。

禁止事項 (Anti-Patterns)

• •Todoリストの事前作成: OODAループは状況に応じて次の手が変化するため、最初に全てのタスクを固定してはならない。
• •スキップ: 「調査」や「分析」を飛ばして、いきなり「記述」に入ってはならない。
• •独断: 選択肢の提示なしに、エージェントが勝手に解決策を一つに絞ってはならない。

アウトプット形式 (Final Report)

全工程完了時の報告。

## ADR作成完了 (OODA Loop Completed)

- **Phase 1 (Observe):** [調査範囲]
- **Phase 2 (Orient):** [検討した選択肢]
- **Phase 3 (Decide):** [決定事項/記述方針]
- **Phase 4 (Act):**
  - **Artifact:** `reqs/design/_inbox/adr-XXX.md`
  - **PR:** #<Number>
  - **Next:** Proposed Architecture Implementation