grill-with-docs

この計画のあらゆる側面について、私たちが共通の理解に達するまで容赦なく私にインタビューしてください。設計ツリーの各枝をたどり、意思決定間の依存関係を一つずつ解決してください。各質問について、推奨する回答を提示してください。

質問は一度に一つずつ行い、次に進む前に各質問へのフィードバックを待ってください。

コードベースを調査することで答えられる質問であれば、代わりにコードベースを調査してください。

ドメインの把握

コードベースの調査中に、既存のドキュメントも探してください：

ファイル構造

ほとんどのリポジトリには単一のコンテキストがあります：

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

ルートに CONTEXT-MAP.md が存在する場合、そのリポジトリには複数のコンテキストがあります。マップはそれぞれがどこに存在するかを示します：

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

ファイルは必要になったときに作成してください — 書くべき内容があるときにのみ作成します。CONTEXT.md が存在しない場合は、最初の用語が解決されたときに作成してください。docs/adr/ が存在しない場合は、最初の ADR が必要になったときに作成してください。

セッション中

用語集との突き合わせ

ユーザーが CONTEXT.md の既存の言語と矛盾する用語を使用した場合、すぐに指摘してください。「あなたの用語集では『cancellation』を X と定義していますが、あなたは Y を意味しているようです — どちらですか？」

曖昧な表現を研ぎ澄ます

ユーザーが曖昧な用語や多義的な用語を使用した場合、正確な正規の用語を提案してください。「あなたは『account』と言っていますが、Customer と User のどちらを意味していますか？それらは別のものです。」

具体的なシナリオを議論する

ドメインの関係性が議論されているとき、具体的なシナリオでそれらをストレステストしてください。エッジケースを探り、概念間の境界についてユーザーに正確さを求めるシナリオを考案してください。

コードと照合する

ユーザーが何かの仕組みを述べたとき、コードがそれに同意するか確認してください。矛盾を見つけた場合は、それを明らかにしてください：「あなたのコードは Order 全体をキャンセルしますが、今あなたは部分的なキャンセルが可能だと言いました — どちらが正しいですか？」

CONTEXT.md をその場で更新する

用語が解決されたら、その場で CONTEXT.md を更新してください。これらをまとめてバッチ処理しないでください — 発生したその時に記録してください。CONTEXT-FORMAT.md の形式を使用してください。

CONTEXT.md を実装の詳細と結び付けないでください。ドメインの専門家にとって意味のある用語のみを含めてください。

ADR は控えめに提案する

以下の三つがすべて当てはまる場合にのみ、ADR の作成を提案してください：

1. 元に戻すのが難しい — 後で考えを変えるコストが意味のあるものである
2. コンテキストなしでは意外 — 将来の読者が「なぜ彼らはこのようにしたのか？」と疑問に思う
3. 実際のトレードオフの結果 — 本物の代替案があり、特定の理由で一つを選んだ

三つのいずれかが欠けている場合は、ADR をスキップしてください。ADR-FORMAT.md の形式を使用してください。