Grilling

---
name: grilling
description: 既存の計画・設計・アイデアを徹底的に尋問し、共有理解に至るまでストレステストする対話スキル。使用タイミング: (1) 「グリルして」「grillして」「この計画を詰めて」「計画の穴を突いて」「ストレステストして」等の依頼時、(2) 実装着手前に計画・設計の前提や未決定事項を洗い出したい時。境界: ゼロからの要件定義・要件書作成→design-feature、完成した文書の多角的レビュー→doc-review。本スキルは既に存在する計画・アイデアの対話的な検証を行う。要件書等の成果物は生成せず、確定した重要決定のみADRとして.local/docs/に記録する。
---

# Grilling

計画・設計のあらゆる側面をユーザーにインタビューし、設計ツリーの各分岐を1つずつ解決しながら、共有理解（shared understanding）に至るまでストレステストする。

出典: [mattpocock/skills の grilling](https://github.com/mattpocock/skills) を既存規約にフル適合させたもの。

> 用語注記: 本スキルの「AskUserQuestion」はユーザーへの選択肢提示質問を指す。Claude Code では AskUserQuestion ツール（1回最大4問）を使い、無い環境（Codex 等）では番号付き選択肢のテキスト質問で代替する（1回4問の上限も同様に扱う）。

## 原則

- **独立枝はまとめる、依存枝は1つずつ**: 互いに前提を変えない独立した枝は1回の AskUserQuestion で最大4問までまとめて聞く（AskUserQuestion の上限は4問）。回答が後続の質問の前提を変える依存関係のある枝は、従来どおり1問ずつ降りる。判断に迷ったら1問ずつが安全側
- **推奨回答を必ず添える**: 各質問に自分の推奨案と根拠を提示する
- **設計ツリーを枝ごとに降りる**: 決定間の依存関係を意識し、前の回答が後の質問の前提を変える箇所ではまとめず順に解決する
- **調査で答えが出る質問はユーザーに聞かない**: コードベース・公式ドキュメントの調査で確定できる事項は自分で調べて確定し、事実として提示する（推測禁止・調査先行の最優先指示と整合）
- **共有理解に至るまで実行しない**: ユーザーが「共有理解に達した」と確認するまで、計画の実行・実装に着手しない

## ワークフロー

### 1. 対象の把握

- グリル対象（計画・設計・アイデア）を特定する。会話中に提示済みならそれを使い、ファイル（30_plan.md 等）が指定されたら読む
- 対象に関連する既存コードがあれば先に調査し、事実ベースの質問を組み立てる

### 2. 尋問ループ

- **AskUserQuestion で質問する**。独立した枝は1回のツール呼び出しで最大4問までまとめ、依存関係のある枝は1問ずつ降りる。推奨案は先頭オプションに置き、ラベル末尾に「（推奨）」を付ける。選択肢化が不自然な自由回答型の質問のみテキストで聞く
- 質問の観点例: 目的・成功条件 / スコープ境界 / エッジケース / 依存関係と順序 / 技術選定の根拠 / 運用・移行・ロールバック / 非機能（性能・セキュリティ）
- 回答によって前提が変わったら、影響を受ける未解決の枝に戻って質問し直す
- ユーザーの回答が既存コード・事実と矛盾する場合は、調査結果を添えて指摘する

### 3. 収束

- 未解決の枝がなくなったら、合意事項・却下した代替案・残リスクをサマリとして提示し、共有理解に達したかユーザーに確認する
- サマリ提示時に、ADR条件（下記）を満たす決定があればADRとして記録する
- 確認が取れるまで実装・実行には移らない

## 決定の記録（ADR等 → .local/docs/）

グリル中に確定した決定のうち、以下の3条件を**すべて**満たすものは、ADRとして `${MEMORY_DIR}/docs/adr/NNNN-<slug>.md`（MEMORY_DIR未定義時は `.local/docs/adr/`）に保存する:

1. **覆しにくい**: 後から方針転換するコストが大きい
2. **文脈なしでは不可解**: 将来の読者がコードだけを見て「なぜこうした？」と不思議に思う
3. **実在したトレードオフの結果**: 本物の代替案があり、特定の理由で選んだ

3条件を満たさない決定は記録しない（覆しやすい決定は覆せばよく、自明な決定は誰も理由を問わない）。

- **形式**: タイトル＋1〜3文（文脈・決定・理由）で足りる。セクションを埋めること自体に価値はない。決定が再訪されそうな場合のみ Status（proposed / accepted / deprecated / superseded by ADR-NNNN）を、却下理由が非自明な場合のみ「考慮した選択肢」を追加する
- **連番**: `docs/adr/` 内の最大番号+1。ディレクトリは最初のADRが必要になった時に遅延作成する
- **用語集**: グリル中に用語の揺れ（同じ概念への複数の呼び名）が問題になったら、`.local/docs/context.md` に推奨語と回避語（_Avoid_）を記録する
- **境界**: タスク限りの「やらない判断」は従来どおり 99_history.md。タスクを超えて残すべき設計決定のみADRにする
- **worktree内での実行時**: メモリファイル同様、元repoの絶対パスに書く（@AGENTS.md「worktree 運用ルール」）

## 既存設定との関係

- **Phase 0-5（@context/workflow-rules.md）**: Phase 2（計画）の補完。複雑タスクの計画をグリルした場合、合意事項を 30_plan.md に反映し、経緯を 05_log.md に記録する。却下した代替案は 99_history.md に記録する
- **メモリディレクトリ（@context/memory-file-formats.md）**: 既存構造を使用。加えて、ADR条件を満たす決定のみ `${MEMORY_DIR}/docs/` に記録する（上記「決定の記録」参照）
- **AskUserQuestion運用（@AGENTS.md）**: 「曖昧な点は推測せず質問する」ルールの実行手段として機能する

## 既存設定への参照

- @context/workflow-rules.md
- @context/memory-file-formats.md