grilling について
grillingは、workflow-axa向けの要件確認スキルで、分岐する意思決定ツリーに沿ってユーザーに質問します。回答と未決の選択肢を記録し、実装前に重要な判断を整理します。
主な機能
- 01分岐型意思決定ツリーによる質問
- 02前提が確定した質問を段階的に提示
- 03環境上の事実を独自に調査
- 04回答と未決事項の記録
- 05失敗ケースを含むフローの確認
活用シーン
- 01新しい目標の要件整理
- 02変更タスクの選択肢の解決
- 03呼び出し元や境界ケースの見落とし発見
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ gazohhh/ workflow-axa --skill grillingインストール後、Claude Code で/grillingを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yamlLICENSE
詳細
mattpocock/skills の
skills/productivity/grilling/SKILL.mdにある workflow-axa に同梱されています(4ae2317、MIT(LICENSE))。以下の上流テキストは変更されていません。末尾の workflow-axa による適用は、内容が矛盾する場合に優先されます。
共通認識に達するまで、ユーザーに徹底的に質問してください。これを設計ツリーとして整理します。すべての決定から、それに紐づく決定へと枝分かれします。
ツリーをラウンドに分けて進めます。フロンティアとは、前提となる決定がすでに確定しているすべての決定、つまり、まだ聞いていない回答を推測せずに今質問できる項目のことです。各ラウンドでは、フロンティア全体について質問します。質問には番号を付け、それぞれに推奨する回答を示します。その後、次のラウンドに進む前にユーザーの回答を待ちます。
ラウンドは次のように記述します。
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
---
❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
各質問は、「はい」と答えると推奨する回答を採用する形にしてください。
ユーザーの回答を受けるたびにツリーが変化します。確定した決定によってフロンティアが広がり、それに依存する質問が可能になります。フロンティアを再計算し、次のラウンドの質問をしてください。このラウンドでまだ未確定の別の質問に回答が依存する質問は、後のラウンドに回します。
_事実_を調べるのはあなたの役目です。ユーザーに任せてはいけません。フロンティアの質問に、環境(ファイルシステム、ツールなど)から得られる事実が必要な場合は、新しいコンテキストウィンドウでサブエージェントを起動して調べてください。調査を待ってはいけません。調査中の項目は未確定の前提条件であるため、それに依存する質問だけをサブエージェントの報告まで保留し、残りのフロンティアについては今すぐ質問してください。_決定_はユーザーが行うものです。選択肢を提示して、回答を待ってください。
フロンティアが空になったら、セッションは完了です。設計ツリーのすべての枝が検討され、暗黙のままになっている項目はありません。その共通認識に達したことをユーザーが確認するまでは、実行に移してはいけません。
workflow-axa による適用
上記は方法です。これらのルールがそれに加わり、異なる場合は優先されます。workflow-clarify のステップ 2 で実行されます。新たに重要な選択肢が見つかったフェーズは、その枝についてのみここに戻ります。
適用する場合
長いプロンプトの場合や、コードの所有者が明らかな場合も含め、新しい実質的な目標や重要な変更のたびに質問を重ねてください。目的は、誰も言及していない決定事項を見つけることです。軽微な編集、説明、単一のアクセスに関する質問では省略してください。ユーザーが「質問は不要」と言った場合は、その旨を記録し、保護対象の事項を自分で決めるのではなく、ラベル付きの選択肢を提示してください。
依頼の内容が完全であれば、質問が不要な場合もあります。選択肢が確定している理由を記録してください。質問の最低数も、ラウンド数の上限もありません。
最初のラウンドの前に
質問はチェックリストではなく、workflow-clarify のステップ 1 でたどったユーザーの操作経路から導き出します。まだ追跡していない呼び出し元に回答が依存する質問はしないでください。追跡によって、その質問自体が不要になることもよくあります。方向性、アクセス、安全性に関する障害はすぐに質問し、残りの追跡は続けてください。
見つけたものを分類する
| 項目 | 内容 | 根拠となるもの |
|---|---|---|
| 事実 | 現在の動作 | コード、コマンドの出力、一次資料。自分で調べ、必要な事実を確認できない場合に限り、何を確認したかを伝えて質問します |
| 要件 | ユーザーが求めた動作 | ユーザーの発言、または記録された回答 |
| 前提 | まだ確認されていない認識 | ユーザーが異議を唱えられるよう、合意事項に明記します |
| 未決の選択 | 実装内容を変えるユーザーの判断 | 選択肢と推奨案を添えた番号付きの質問。ルールで禁止された選択肢は含めません(UI の場合、新しい CSS は不可) |
| 推奨案 | 提案 | 決定として扱うことはありません |
| 委任された詳細 | 合意済みの範囲内での実装上の選択で、製品を使う人には気づかれないもの | プロジェクトの慣例、または記録された委任事項 |
この変更によって以前と異なる、ユーザーが目にしたり気づいたりするもの(レイアウト、間隔、文言、タイミング、既定値)はすべて未決の選択です。ただし、既存の決定、承認済みのポリシー、またはユーザーからの明確で範囲が限定された委任によってすでに決まっている場合は除きます。自分で決めた選択はそれぞれ DECISIONS に by: agent と記録し、納品時に列挙します。
コードが示すのは現在の動作であり、意図ではありません。以前のエージェントによる提案、図、沈黙、または回答が一部にとどまる一括質問は、決定ではありません。リクエストが意図的に変更しようとしている動作は、まさに取り組む対象です。リクエスト、コード、ドキュメントの間に説明のつかない食い違いがあれば、質問してください。
質問する前に、過去の DECISIONS と、プロジェクトが AGENTS.md に記載している「継続的な回答」を確認してください。ユーザーがすでに恒久的に決めたことを、もう一度尋ねてはいけません。「常に」と言われた場合は、そこに記録することを提案してください。
質問の仕方
ホストに構造化された選択式の質問ツールがある場合はそれを使い、ない場合はチャットで質問してください。回答が届かないままになるような、裏での聞き取りをしてはいけません。プロジェクトに不慣れな人にも伝わるよう、各質問では(../workflow/WRITING.md を参照)、現在の動作、選択肢、推奨案とその結果、回答によって影響を受ける内容を説明します。早めに質問し、回答によって次に進める作業の安全性や有用性が変わる場合は、その作業を一時停止します。後回しにできる選択肢はまとめて質問し、重要でない不明点には値を勝手に作らず、未確定であることを明記します。
停止する前に問題を洗い出す
「未解決の論点がない」とは、把握できている質問が残っていないことを意味します。各ユーザーフローについて、ドラフトが誤りとなる現実的な入力、状態、呼び出し元を1つ挙げます。たとえば、2つ目の呼び出し元、空または巨大なデータ、古い保存データ、権限に関する境界ケース、中断された実行、同時利用などです。それぞれを、事実、要件、明示された前提、または新たな質問によって解決します。
次のすべてを満たしたら停止します(「未解決の論点がない」に代わる条件です)。
- 各ユーザーフローについて、成功時と関連する失敗時の観測可能な結果がある。
- 見つかったすべての呼び出し元と互換性に関する依存関係が、いずれかのユーザーフローに含まれているか、明示的に対象外とされている。
- 次の作業を妨げるすべての選択肢が回答済み、範囲を限定して委任済み、またはユーザーによって保留とされている。
- 問題の洗い出しで、重要な未解決事項が残っていない。
ユーザーにしか決められない場合、2回やり取りしても新たな情報が得られない場合、必要な機能がない場合、または予算に達した場合は、同じ質問を繰り返さず、エスカレーションしてください。調査は未決の選択肢を記録した状態で終えても構いませんが、実装はその状態で終えてはいけません。
回答を記録する
タスクの担当者は回答が届き次第保存するため、中断しても途中までの回答が残ります。FINDINGS に簡潔な判断確認(ジャーニーまたは領域、項目、回答と情報源、または未解決の質問)を記録し、重要な選択肢は DECISIONS に記録します。未解決の質問は、送信する前に、選択肢、記号、推奨内容を一字一句そのまま保存してください。そうすれば、後のセッションでチャット履歴がなくても「Q1 a」のような返信を読み取れます。メッセージの作成中に質問を変更した場合は、まず保存済みの内容を更新してください。保存した選択肢と送信した選択肢、および推奨内容は完全に一致している必要があります。会話の記録も、質問専用ファイルも作成しません。
部分的な返信で確定するのは、返信で扱われた項目だけです。「すべての推奨案に賛成です」で確定するのは、実際に提示した項目だけです。対象が示されていない一般的な「進めてください」では、何も確定しません。範囲を限定した委任は、ユーザーが選択肢を選んだのではなく、委任として記録します。
共通認識
「共通認識に達したことを確認する」は第 1 のゲートです。workflow-clarify のステップ 4 にある合意内容の要約がこれに当たります。その前に、「理解できていますか?」という中身のない確認を追加しないでください。ヒアリングを終えても何も確定せず、コード作成が許可されることもありません。