grill-me

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

ツリーはラウンドごとに進めます。各ラウンドはまず調査から始めます。次の質問に必要な事実をすべて確認してください。最初のラウンドでは、コードベース、CONTEXT.md、ADR の調査も含まれます。サブエージェントを並行して派遣し、事実を探してください。調査は、すべてのサブエージェントから報告が届いた時点で完了です。その後に初めて、フロンティアを割り出します。前提条件がすでに確定しているすべての決定、つまり、まだ得ていない回答を推測せずに今質問できる項目がフロンティアです。フロンティア全体について、1 回のラウンドで質問してください。質問には番号を付け、推奨する回答も提示します。その後、次のラウンドに進む前にユーザーの回答を待ちます。

各質問は次の形式にしてください。

❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>

ユーザーの回答によってツリーは毎ラウンド組み替えられます。確定した決定によってフロンティアが広がり、前提となる質問が未解決だったために保留されていた質問が可能になります。新たな枝で必要となる事実を調査し、フロンティアを再計算して、次のラウンドの質問を行ってください。回答が同じラウンド内で未解決の別の質問に依存する質問は、そのラウンドではなく、後のラウンドで扱います。

事実を見つけるのはあなたの役割であり、ユーザーに任せてはいけません。環境（ファイルシステム、ツールなど）から確認できることはすべて調べてください。ラウンドの質問を送る前に、必ず調査を完了してください。サブエージェントが動いている間は、すべての質問を保留し、調査中であることを一文でユーザーに伝えてください。質問はすべて事実に基づくものとし、報告が届いた後に撤回が必要になるような質問はしません。決定するのはユーザーです。決定事項をユーザーに提示し、回答を待ってください。

フロンティアが空になったらセッションは完了です。設計ツリーのすべての枝が検討され、暗黙の前提が残っていない状態です。共通認識に達したことをユーザーが確認するまでは、何も実行しないでください。

ドメインに関する注意事項

コードベースを調べる際は、既存のドキュメントも確認してください。

ファイル構成

ほとんどのリポジトリには、コンテキストが 1 つあります。

/
├── 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 には実装の詳細を一切含めないでください。CONTEXT.md を仕様書、作業メモ、実装上の決定を記録する場所として扱ってはいけません。用語集以外のものではありません。

### ADR の提案は控えめに

次の3つすべてに当てはまる場合にのみ、ADR の作成を提案します。

1. 元に戻しにくい — 後から方針を変えるコストが大きい
2. 背景がなければ意外に感じる — 将来の読者が「なぜこの方法にしたのだろう？」と思う
3. 実際のトレードオフの結果である — 現実的な選択肢が複数あり、具体的な理由に基づいてそのうちの1つを選んだ

3つのうち1つでも欠けている場合は、ADR を作成しません。ADR-FORMAT.md の形式を使用してください。

---

mattpocock/skills に基づいています。MIT © 2026 Matt Pocock。このファイルをコピーする場合は、この行を残してください。