grill-meスキルの使い方：導入から計画レビューまで

grill-me は計画の穴を質問でつぶすスキル

grill-me は、エージェントに作業を任せる前に、計画の未決事項を質問で洗い出すスキルです。Matt Pocock 氏の GitHub リポジトリ mattpocock/skills に含まれ、/grill-me と入力すると始まります。新しい会話で計画を伝え、番号付きの質問に答え、すべて決まったと確認してから作業に移ります。要件整理や計画レビューに使え、対象はコードに限りません。

Agent Skills は、SKILL.md を含むフォルダーで手順や知識をエージェントに渡すオープンな形式です。2026年11月9日時点で、同リポジトリのスターは約31.9万です。grill-me は人気も高く、skills.sh の全期間ランキングで2位（約150万インストール）に入っています。

導入手順：grilling も一緒に入れる

grill-me の本体は、別スキルの grilling を呼び出す1行だけです。そのため、grill-me だけを入れても正しく動きません。この問題は Issue #1319 で報告されており、2026年11月9日時点で未解決です。

# Claude Code（スキル一式を導入）
claude plugin install mattpocock-skills@claude-plugins-official

# そのほかのエージェント（2つだけ導入）
npx skills@latest add mattpocock/skills --skill grill-me --skill grilling -a <agent>

<agent> には claude-code や codex、cursor などを指定します。全プロジェクトで使うなら -g を付けます。grill-me だけを使う場合、/setup-matt-pocock-skills の実行は不要です。これは開発系スキル向けの設定です。

導入後は次の順に進めます。

1. 新しい会話を開きます。別のエージェントが書いた計画の続きでは始めません。
2. プランモードをオフにします。オンだと、エージェントが質問より計画の作成を急ぐためです。
3. /grill-me と入力し、検討したい計画やアイデアを伝えます。
4. 質問の形式を確認します。推奨回答がなく、すべてを一度に聞いてくる場合は、grilling を読み込んだかエージェントに尋ねます。

質問は決定事項の依存関係に沿って進む

grilling は計画を「設計ツリー」として扱います。ある決定から、それに依存する次の決定へ枝分かれする構造です。前提がすでに決まっていて今すぐ問える決定事項を、スキルは「フロンティア」と呼びます。

1回のラウンドでは、フロンティアの質問をまとめて出します。各質問には番号と推奨回答が付き、エージェントは回答を待ちます。答えが出るとフロンティアを計算し直し、次のラウンドに進みます。他の質問の答えに左右される質問は、後のラウンドに回ります。

社内問い合わせへのチャットボット導入を題材にすると、次のような形です（形式を日本語にした架空の例です）。

❓ Q1 - 対象範囲: 最初は IT の問い合わせだけを対象にしますか？
➡️ はい。回答の正否を確認しやすい範囲から始めます。
---
❓ Q2 - 答えられない場合: 担当者へ引き継ぐ形にしますか？
➡️ はい。誤回答の影響を抑えられます。

範囲が IT に決まると、次のラウンドで「どの FAQ を回答の根拠にするか」を問えるようになります。公式ドキュメントでは、13問がおよそ3ラウンドに収まるとされています。46問・4ラウンドも普通の例として挙げられており、質問数に上限はありません。

事実はエージェントが調べ、判断は人が決める

grilling の役割分担は明確です。ファイルやツールなど環境から分かる事実は、サブエージェントが調べます。人には聞きません。調査の結果を待つのはそれに依存する質問だけで、残りの質問は先に出します。

場面（例）	エージェントが調べる事実	人が決める判断
API の移行	現行の呼び出し箇所	旧 API をいつ止めるか
業務計画	共有された前年の手順書の内容	今年変える範囲と担当
新規企画	手元にある調査資料の内容	誰に向けて何をしないか

エージェントが調べられるのは、アクセスできる範囲だけです。企画や業務の計画では、必要な資料を先に渡しておきます。エージェントが判断まで自分で答えた場合、公式ドキュメントはこれを不具合として扱っています。その場で指摘し、判断を人に戻します。

質問への答え方

回答は番号で返せます。公式ドキュメントの例を訳すと「1 は yes、2 は2番目の案、3 は no、理由は…」という形です。質問は、yes で推奨回答を受け入れられる文面にするよう指示されています。ただし、推奨回答が質問の文面に反対していることもあります。その場合は「推奨どおり」と明記します。

答えるときは次の点を意識します。

• 同意を続けるだけにしない：公式ドキュメントは、これを主な失敗に挙げています。計画が実際より確かに見えてしまうからです。
• 分からなければ「分からない」と答える：これも正式な回答とされています。
• 範囲は自分で管理する：話が広がったら指摘し、質問が粗ければ押し返します。
• 順序の誤りを伝える：依存する質問が同じラウンドに混ざったら、どの答えが他方を変えるかを伝えます。
• 他の人の判断は切り分ける：自分で決められない事項は、to-questionnaire で相手向けの質問票にできます。

対話を終えて作業に移る判断

終了の条件は、フロンティアが空になり、すべての枝を確認し、暗黙の前提が残っていないことです。そのうえで人が共通理解を確認するまで、エージェントは計画を実行しません。先に作業を始めてしまう場合は、AGENTS.md や CLAUDE.md に許可なく実装しないよう書きます。

移る前に、公式ドキュメントが挙げる目安を確かめます。

• エージェントの案に反対した箇所があるか
• 質問が前の答えを踏まえて深まったか
• 各判断の理由を、その場にいない人へ説明できるか

終わらないときの対処も決まっています。

• 長引く：範囲が大きすぎる可能性があります。分割して個別に進めます。長すぎる対話では質問の質も落ちます。
• 早く切り上げたい：まとめるよう指示するか、現状の計画を受け入れると伝えます。
• 話しても決まらない：画面の操作感などは、prototype で試作してから答えます。

対話の後に使うスキル

grill-me はファイルを残しません。結論は会話の中にあるので、会話を閉じる前に次の手を打ちます。企画や業務計画なら、同じ会話で文書にまとめるよう頼みます。

目的	使うもの
ソフトウェアの仕様にする	同じ会話のまま to-spec
依存順のチケットに分ける	to-tickets
別のエージェントに引き継ぐ	handoff
コードベースで用語集や ADR（設計判断の記録）も更新する	最初から grill-with-docs

to-spec と to-tickets には /setup-matt-pocock-skills の設定が必要です。grill-with-docs は grilling に加えて domain-modeling も必要とします。逆に、作業内容をすでに正確に指定できるなら、grill-me を使う必要はありません。