drill

検討中の計画または設計に対して、core-interview スキルを実行します。このインタビューでは、プロジェクトのドメインモデルに照らして計画も検証します。

最短ルート：docs/specs/ に依頼をすでに網羅している確定済みの仕様書がある場合は、直接 implement に進みます。それ以外の場合は、まず依頼を内部で明確にします。一流の専門家ならどのように取り組むかを考えます。情報源、手法、そして結果を証明する外部チェックを確認します。外部チェックとは、テストランナー、稼働中のシステム、独立した情報源など、作業の外部から得られる証拠です。ユーザーが本当に求めていること、そして依頼の範囲が広すぎないか、狭すぎないかを確認します。その目的に役立たない制約は取り除きます。結果を改善するものだけを加え、作業の規模は大きくしません。ユーザーが決めるべき選択肢は未決のままにします。以下の一文の計画を除き、言い換えた依頼をユーザーに見せてはいけません。次に、依頼の規模を見極めます。実質的な判断の分岐がない依頼は明白です。たとえば、明白な変更が一つだけの場合、小さな差分の場合、または一文で述べられる基準がある場合です。依頼が明白であると伝え、その一文を計画として implement に進みます。その一文には、基準として外部チェックを含めます。明白な変更について仕様書を書いてはいけません。最短ルートでも、その一文を検証します。一文を述べてから、それを検証します。一文で述べられない場合、またはその一文に判断すべきことが含まれている場合、依頼は明白ではありません。その場合はインタビューを実施します。

1. 最初の質問をする前に、コード、ドキュメント、最近のコミットを読み、プロジェクトのコンテキストを確認します。
2. 最初の質問をする前に、ルートに CONTEXT.md があるか確認します。CONTEXT-MAP.md と、そこに記載された各 CONTEXT.md も確認します。docs/adr/ にある ADR に加え、特定のコンテキストだけに適用される ADR も確認します。
3. CONTEXT.md のない、規模の大きいコードベースでは、コードやドキュメントから候補となる用語を集めることを提案します。インタビュー中に各用語をユーザーに提示します。ユーザーが確認した用語だけを用語集に追加します。
4. 依頼に独立した部分が複数ある場合は、その旨を伝えます。最初の部分を詳しく確認し、ほかの部分は後で扱います。
5. 方向性を決める前に、互いに異なる2つまたは3つのアプローチと、それぞれのトレードオフを示します。同じアプローチのバリエーションではなく、異なるアプローチを示します。exhaust the design space に従い、推奨案を最初に示します。既存の設計に新しい要件が加わる場合は、redesign from first principles も一つのアプローチです。各アーキテクチャの形を design red flags に照らして確認します。見た目、感触、フローに関する判断の中には、文章だけでは決められないものがあります。そのような場合は prototype スキルを実行し、ユーザーが評価できる使い捨てのプロトタイプを作成します。ユーザーが方向性を選んだら、プロトタイプは破棄します。
6. 判断の分岐がすべて解決したら、セッションを終了します。その後、確定した設計を短く要約します。実装を始める前に、ユーザーから明示的な同意を得ます。
7. 確定した設計が実装作業である場合は、対象プロジェクトの docs/specs/<slug>.md に仕様書を書きます。spec-format.md に従い、目標、対象外の事項、検証可能な受け入れ基準、検証コマンド、段階的な移行の場合はフェーズを記載します。最短ルートで使う外部チェックを検証コマンドに含めます。
8. このセッションでは判断の分岐を解決できない場合もあります。判断に必要な調査をこのコンテキストの外で行う必要がある場合や、一度のセッションで扱うには分岐が多すぎる場合などです。その場合、確定していない設計について確定済みの仕様書を書いてはいけません。代わりに、仕様書をドラフトとして作成します。draft-spec.md に従ってください。

ルール：

• 記載された制約が求めていないものはすべて設計から取り除いてください。残ったものを体験優先に照らして確認してください。製品のスコープ、UX、インターフェースに関するトレードオフで、構築の容易さと利用者の体験が対立する場合は、こちらを読んでください。
• 内容がある場合にのみファイルを作成してください。最初に確定した用語ができた時点でCONTEXT.mdを、最初のADRができた時点でdocs/adr/を作成してください。
• インタビューでは、ユーザーに用語集に従ってもらってください。 ユーザーがCONTEXT.mdとは異なる意味で用語を使ったら、すぐに指摘してください。たとえば、「用語集ではRefundをXと定義しています。Yの意味で使っているようですが、どちらですか？」と尋ねてください。
• インタビューでは、曖昧な言葉を置き換えてください。 曖昧な言葉や、複数の意味がある言葉には、正確な用語を提示してください。たとえば、「『ユーザー』とはAccount holderとOperatorのどちらを指しますか？ それぞれ別の役割です」と尋ねてください。
• インタビューでは、具体例で確かめてください。 2つの概念が交わるところでは、その境界にある具体例を選び、どうなるかを尋ねてください。
• インタビューでは、コードと照らして主張を確認してください。 ユーザーが動作を説明したら、コードを確認してください。違いがあれば、それぞれ明示してください。たとえば、「コードはPayment全体を返金します。部分返金の説明でしたが、どちらが正しいですか？」と尋ねてください。
• インタビューでは、用語が確定した時点で記録してください。 用語が確定したら、最後まで待たずにCONTEXT.mdを更新してください。ここに記載するのは用語集のみです。計画、メモ、実装上の選択は記載しません。terms.mdの形式を使用してください。
• インタビューでは、ADRの作成は慎重に判断してください。 decision-record.mdにある3つの条件を満たす決定についてのみ、ADRを提案してください。その決定は、元に戻すのにコストがかかり、コードからは判断の経緯が分かりにくく、実際の代替案と比較して選ばれたものである必要があります。
• 後続のセッションでは草案を扱います。 セッションで開いた仕様書にまだ## Open decisionsセクションがある場合は、draft-spec.mdに従ってください。