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 に記載された用語と矛盾する用語を使った場合は、すぐに指摘してください。「用語集では『キャンセル』を X と定義していますが、今おっしゃっているのは Y のようです。どちらでしょうか？」

曖昧な表現を明確にする

ユーザーが曖昧な用語や複数の意味に取れる用語を使った場合は、正確な標準用語を提案してください。「『アカウント』と言っていますが、Customer と User のどちらを指していますか？この二つは別のものです。」

具体的なシナリオを検討する

ドメイン上の関係について話し合うときは、具体的なシナリオで検証してください。境界条件を探り、概念間の境界を明確にするためのシナリオを考案してください。

コードとの照合

ユーザーが仕組みについて説明したら、コードと一致しているか確認してください。矛盾が見つかった場合は、指摘してください。「コードでは Order 全体をキャンセルしていますが、先ほど部分キャンセルが可能だとおっしゃいました。どちらが正しいですか？」

CONTEXT.md をその場で更新

用語が確定したら、その場で CONTEXT.md を更新してください。まとめて後から記録しないでください。記載形式は CONTEXT-FORMAT.md に従ってください。

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

ADR の提案は必要最小限に

次の条件をすべて満たす場合に限り、ADR の作成を提案してください。

1. 変更が難しい — 後から変更する場合に相応のコストがかかる
2. 背景がないと意外に感じられる — 将来の読者が「なぜこのようにしたのか」と疑問に思う
3. 実際のトレードオフの結果である — 真剣に検討した複数の選択肢があり、具体的な理由で一つを選んだ

いずれかの条件を満たさない場合は、ADR を作成しないでください。記載形式は ADR-FORMAT.md に従ってください。

---

mattpocock/skills からベンダー提供されたものです（コミット b843cb5、MIT ライセンス）。更新手順については skills/UPSTREAM-CREDITS.md を参照してください。