design-interviewlisted

# 設計インタビュー ユーザーの設計書・計画を、実装に入る前に徹底的に問い詰め、認識のズレをなくす。 ## 進め方 1. 作業スコープ直下に CONTEXT.md があれば先に読み、用語の解釈をそれに合わせる。 2. 対象の設計書(通常は docs/drafts/ 配下)を読み込む。指定がなければ、直近の 会話や docs/drafts/ の中から対象を確認する。 3. 決定木を1枝ずつ辿る。各分岐で、未確定な判断を1つ特定する。 4. 質問は必ず1問ずつ出す。複数の質問を同時に出さない。 5. 各質問には、こちらの推奨案を添える(例:「Aが良いと考えます、理由は〜」)。 6. コードや既存ドキュメントを読めば答えが分かる質問は、ユーザーに聞かず 先に調査する。 7. ユーザーの回答を待ってから次の質問に進む。 8. すべての分岐が解消されたら、決定内容を設計書(docs/drafts/配下)に反映して 更新する。このとき「## 受け入れ条件」セクションを必須で生成する(無ければ新規作成、 あれば決定事項を反映して更新)。全ての決定を、以下の6列を持つ Markdown テーブルの 検証可能な要件に変換する(このテーブルなしでは Planner が計画作成を差し戻す)。 | 列 | 意味 | |---|---| | ID | `R-001` 形式の連番。設計書内で一意・欠番なし | | 要件 | 検証可能な主張1つ(1行1要件。複合要件は分割する) | | 検証方法 | 実行コマンド(auto)または「(目視)」(manual) | | 期待結果 | `exit 0` / 数値条件 / 「人間承認」など、機械照合できる形式 | | 種別 | `auto` / `manual` | | 対象 | カバレッジ確認する対象モジュール(auto のみ、任意) | 曖昧で検証コマンド化できない決定は、この段階で追加の質問に分解し具体化する。 ## 知識の自動スタック(手順8の直後に必ず実施する) 設計書を更新したら、その内容から以下の3種を検出し、該当ファイルに追記する。 検出ゼロなら追記もゼロで構わないが、「検出したかどうか」の確認自体は必ず行う。 ### (a) 新しい用語・略語 → CONTEXT.md - 設計書に登場した独自の略語・固有名詞・プロジェクト特有の用語で、 CONTEXT.md にまだ載っていないものを検出する。 - 検出したら、作業スコープ直下の CONTEXT.md の「用語一覧」表に追記する。 CONTEXT.md が無ければ「# CONTEXT.md — ドメイン用語集」の見出しと 「| 用語 | 定義 |」の2列テーブルだけの最小構成で新規作成する。 - 一時的な変数名や実装詳細(関数名など)は含めない。 概念として繰り返し使われるものだけを追記する。 ### (b) 重要な設計判断 → adr スキル - トレードオフを伴う決定が2つ以上解消された場合、adr スキルを必ず使って docs/adr/ に記録する。「提案」ではなく、必ず実行すること。 - 決定が1つだけの場合はユーザーに確認してから adr を使う。 - 些細な決定(命名・書式の好みなど)は対象外。 ### (c) 実験の再現条件 → docs/EXPERIMENT_LOG.md - 設計書に具体的な数値・シード値・データセット名・モデル重