tracer-interview-me

共通認識に至るまで、ユーザーに徹底的に質問してください。これを設計ツリーとして整理します。すべての決定から、それに紐づく決定へと分岐します。

ツリーをラウンドに分けて進めます。フロンティアとは、前提となる決定がすでに確定しているすべての決定、つまり、まだ聞いていない回答を推測せずに今質問できる項目のことです。1ラウンドでは、フロンティアにある質問をすべてまとめて行います。各質問に番号を付け、推奨する回答も示してください。その後、次のラウンドに進む前に、ユーザーの回答を待ちます。

ラウンドごとにユーザーの回答を反映してツリーを組み替えます。確定した決定によってフロンティアが広がり、依存していた質問が回答可能になります。フロンティアを再計算して、次のラウンドの質問を行います。回答が同じラウンド内の別の未回答の質問に依存する場合、その質問はこのラウンドではなく、後のラウンドに含めます。

事実を調べるのはあなたの役目であり、ユーザーに任せてはいけません。フロンティアの質問で環境（ファイルシステム、ツールなど）に関する事実が必要な場合は、新しい探索サブエージェントを1つ起動して調査させます。ユーザーに、自分で調べられることを尋ねてはいけません。調査はそのエージェントが担当し、返された根拠をもって事実確認を完了します。調査の完了を待って進行を止めてはいけません。探索が進行中なら、その確認は未確定の前提です。したがって、サブエージェントから報告があるまで待つのは、その確認に依存する質問だけです。それ以外のフロンティアの質問は、今すぐ行ってください。決定するのはユーザーです。各項目をユーザーに提示し、回答を待ってください。

コードベースがある場合（状態あり）

リポジトリ内で実行する場合、インタビューではドキュメントの内容を双方向に考慮します。

• 第1ラウンドの前に読む： CONTEXT.md（または CONTEXT-MAP.md と、関連するコンテキスト別ファイル）および対象領域に関係する docs/adr/ の項目を読みます。既存の用語集の項目と ADR は確定済みの決定として扱い、第1問を出す前に設計ツリーから分岐を取り除きます。ドキュメントが存在しない場合は、何も言わずにそのまま進めてください。最初から作成を提案してはいけません。
• 確定時に書き込む： ラウンドで曖昧な用語や複数の意味がある用語が解消されたら、その内容を CONTEXT.md の用語集に記録します。後から変更しにくい決定が確定したら、docs/adr/ に ADR として記録します。/tracer-domain-modeling の規律と書式（CONTEXT-FORMAT.md と ADR-FORMAT.md）に従ってください。用語集には用語だけを記載し、実装の詳細は含めません。ADR を提案するのは、その決定が変更しにくく、背景を知らなければ意外に思われ、かつ実際のトレードオフの結果である場合に限ります。記録は最後にまとめて行うのではなく、確定した時点で行ってください。こうして記録を残すことで、次のセッションではより小さなツリーから始められます。インタビューの内容が既存の ADR と矛盾する場合、それ自体をフロンティアの質問にします。「ADR-NNNN と矛盾しています。これを再検討しますか？」と提示し、ユーザーに判断してもらいます。

コードベースがない場合（状態なし）

リポジトリがない場合、または計画やアイデアがコードベースに属していない場合は、何も読み書きせずに同じインタビューを行います。設計ツリーは会話の中だけに存在します。出力となる共通認識は、同じコンテキストウィンドウを維持することで引き継がれます。

完了

フロンティアが空になり、設計ツリーのすべての分岐を確認し、暗黙のままになっている前提が何もなくなった時点でセッションは完了です。ユーザーが共通認識に至ったことを確認するまで、それに基づいて行動してはいけません。

その後、引き継ぎます： ユーザーの確認後、/tracer-to-spec を提案します。確定したツリーは、まさにそこから仕様へとまとめられます。インタビュー全体と仕様の作成は、中断せず同じコンテキストウィンドウ内で行ってください。