AIにコードを書いてもらうとき、いきなり「これを作って」と頼んでいませんか？
その方法でもコードは出てきます。ただし、完成してから「思っていたものと違う」と気づくことがあります。
Matt Pocockさんの/grill-meと/code-reviewは、この問題を前後から支えるSkillです。さらに、Codexや作業環境そのものが正常かを確認する/doctorもあります。
- 作る前：
/grill-meで、考えを質問によってはっきりさせる - 作った後：
/code-reviewで、変更が正しく作られ、要求どおりか確認する - 環境が怪しいとき：
/doctorで、CodexやSkillの状態を診断する
この記事では、3つのSkillの違いと、どんな場面で使うべきかを紹介します。
Matt Pocockとは
Matt Pocockさんは、TypeScriptを中心に活動してきた教育者・コンテンツクリエイター・エンジニアです。本人のプロフィールでは、元ボイスコーチ、Vercel勤務を経て、現在はAIエンジニアリングを教えていると紹介されています。
Total TypeScriptの公式サイトでは、XStateのコアチーム、VercelのDeveloper Advocate、リード・フルスタック開発者、ライブラリメンテナーを経験したことが説明されています。TypeScriptを深く学ぶための教材を作り、オープンソースのメンテナーや業界の専門家の知見を、実践的な演習で学べる形にしてきた人物です。
現在はAI Heroを通じて、Web開発者がAIエンジニアリングを学ぶための教育にも取り組んでいます。今回紹介する/grill-me、/code-review、/doctorは、単なる便利コマンドではなく、こうした開発者教育の考え方をAIとの開発手順に落とし込んだSkillとして見ると理解しやすくなります。
画像出典：Matt Pocock公式プロフィール
`/grill-me`は、作る前に考えを深掘りするSkill
/grill-meは、まだ固まっていないアイデアを質問で掘り下げるSkillです。
AIがすぐに実装を始めるのではなく、複数回の質問を通して、目的、対象ユーザー、範囲、例外、完了条件を整理します。
公式の説明では、何かを始める前にアイデアの認識を合わせ、決断できる状態まで質問するSkillとされています。リポジトリにファイルを書き残すタイプではなく、会話の中で考えを明確にする、ステートレスなSkillです。
`/grill-me`が実際にすること
/grill-meは、最初から完成した計画を出すSkillではありません。質問と回答を何ラウンドか繰り返し、暗黙の前提を減らしていきます。
- まず「記事に検索機能を付けたい」のような、粗いアイデアを受け取る
- その時点で前提がそろっている質問をまとめて出す
- 回答をもとに、次の判断に必要な質問へ進む
- 目的、範囲、例外、完了条件を説明できる状態で終わる
この「その時点で聞ける質問のまとまり」を、公式説明ではfrontierと呼んでいます。前の回答に依存する質問を先走って聞かないため、質問が一つずつ延々と続く形になりにくいのが特徴です。
ただし、質問に答えればすべて決められるわけではありません。「画面は1枚と3枚のどちらがよいか」「操作感をどうするか」のように、実物を見ないと判断できない問題もあります。その場合は、質問を続けるのではなく、簡単な試作品を作ってから/grill-meに戻ります。
また、これは面接ではなく会話です。AIの質問にすべて「はい」と答えるのではなく、前提が違えば反論し、「わからない」ならそう答えます。良い結果の目安は、質問の数が多いことではなく、自分が各判断の理由を説明できることです。
使うべき場面
次のような状態なら、/grill-meを使う価値があります。
- 新しい機能を作りたいが、何を作るか曖昧
- 「もっと使いやすく」「いい感じにしたい」としか言えない
- 作る前に、対象ユーザーや範囲を決めたい
- AIが毎回、勝手に機能を広げてしまう
- 新しい記事、サービス、画面の方向性を整理したい
- 開発途中で時間がかかりすぎている、または迷走している
コードの話でなくても使えます。記事の企画、仕事の進め方、サービス案など、「考えが頭の中にあるけれど、まだ説明できないもの」に向いています。
/grill-meは、作る前だけのSkillではありません。開発途中で「なぜこんなに時間がかかっているのか」「何を作っているのか分からなくなった」と感じたときにも使えます。いったん実装を止めて、目的、範囲、優先順位、不要な機能、完了条件を質問で整理します。作りすぎや迷走に気づきやすくなるため、私は特におすすめしたいSkillです。
`/grill-me`の使い方
Skillをインストールします。
npx skills@latest add mattpocock/skills --skill=grill-me新しい会話で、次のように入力します。
/grill-meすでにAIが作った計画の上に重ねるより、何も決まっていない新しい会話で始めるほうが、/grill-meの役割を活かせます。目的が明確な小さな修正なら、無理に使う必要はありません。
続けて、作りたいものを自然な言葉で説明します。
読者が記事を読んだあと、実際にAI Skillを試せるページを作りたい。質問には、正解らしい答えを無理に返す必要はありません。「わからない」と答えることも有効です。答えられない問題は、先にプロトタイプを作って見てから決めるべき場合があります。
`/code-review`は、作った後の変更を2方向から見るSkill
/code-reviewは、コードの差分をレビューするSkillです。
特徴は、レビューを次の2軸に分けることです。
Standards：このリポジトリの書き方、規約、設計の考え方に合っているかSpec：Issueや仕様書に書かれた要求を正しく満たしているか
つまり、次の2つを別々に確認します。
- 正しく作られているか
- 正しいものを作ったか
たとえば、コードの書き方はプロジェクトの規約に合っていても、仕様と違う機能を作っているかもしれません。逆に、仕様どおりでも、既存の設計ルールを壊しているかもしれません。
この2つを一つの評価に混ぜないことが、/code-reviewの重要な考え方です。
使うべき場面
次のような状態で使います。
- ブランチやPull Requestに差分がある
- AIに実装させた変更を確認したい
- Issueの要求が抜けなく実装されているか知りたい
- 既存プロジェクトの作法に違反していないか確認したい
- マージ前に、独立したレビューを入れたい
ただし、/code-reviewは万能なバグ探しではありません。null参照、競合、境界値などを重点的に探したい場合は、別のバグレビューやテストも必要です。
`/doctor`は、AI開発環境を診断するSkill
/doctorは、コードや計画ではなく、Codexそのものとプロジェクトの作業環境を点検するSkillです。
PATH上のCodex、設定、認証状態、Git、ターミナル、スレッド、Skill、MCP、Plugin、Hook、AGENTS.md、権限、サンドボックスなどを確認し、PASS・WARN・FAILに分けて報告します。通常は読み取り専用の診断です。
使うべき場面
- Codexが急に動かない、または動作が不安定
- Skill、MCP、Plugin、Hookの重複や衝突が疑わしい
- PATHに複数のCodexがありそう
AGENTS.mdや設定が効いているか分からない- 実装や公開の前に、作業環境を点検したい
入力はシンプルです。
/doctorここで大切なのは、Skillを認識できたことと、診断が成功したことは別だという点です。/doctorはコードレビューや要件整理をしません。また、設定・認証・権限を勝手に修正するSkillでもありません。修正やクリーンアップは、内容を確認してから明示的に依頼します。
3つを使う順番
基本の流れは次のとおりです。
作業環境が怪しい
↓
/doctor でCodex・Skill・設定を診断する
↓
アイデア
↓
/grill-me で目的・範囲・完了条件を決める
↓
実装する
↓
コミットする
↓
/code-review で規約と仕様を別々に確認する/doctorは毎回必須ではありません。環境の問題がなさそうなら、/grill-meから始めます。逆に、Skillが動かない状態で計画やレビューを続けるなら、先に/doctorで土台を確認します。
例：読者向けの検索機能を作る場合
最初の依頼が、次のようなものだったとします。
記事を検索できる機能を追加したい。このまま実装すると、AIは検索対象、検索結果の件数、空結果の表示、スマホ画面、URLの扱いなどを推測するかもしれません。
そこで、まず/grill-meを使います。
質問を通して、次のような条件を決めます。
- 検索対象はタイトルだけか、本文も含むか
- 結果が0件のときに何を表示するか
- 検索結果は何件まで表示するか
- 検索URLを共有できるようにするか
- 既存の記事URLや表示を変えないか
- 完了と判断するためのテストは何か
条件が固まったら実装します。
実装後に/code-reviewを使うと、次のような確認ができます。
Standards側の確認
- 既存の検索処理やコンポーネントを再利用しているか
- 命名やファイル配置がプロジェクトの規約に合っているか
- 同じ処理を重複して書いていないか
- 不要な抽象化や設定を追加していないか
Spec側の確認
- タイトルと本文の両方を検索できるか
- 0件の表示が仕様どおりか
- スマホでも検索できるか
- 既存URLを壊していないか
- 完了条件のテストが実装されているか
このように、環境診断・作る前・作った後で役割を分けます。
どのSkillを使うべきか迷ったとき
- 何を作るか決まっていない：
/grill-me - 仕様は決まっていて、まだ実装していない：通常の実装フロー。必要ならTDD
- コードを書いたが、要求を満たすか不安：
/code-review - CodexやSkillの動作、設定、接続が怪しい：
/doctor - リポジトリ固有の用語や設計も整理したい：
/grill-with-docs - 1回の会話に収まらない大きな計画：
/wayfinderなど別の計画Skill
すでに作るものが明確なら、/grill-meを使う必要はありません。逆に、目的が曖昧なまま実装を始めるなら、先に質問の時間を作ったほうが安全です。
注意点
`/grill-me`は、質問されるだけでは効果がない
質問にすべて「はい」と答えているだけでは、AIが作った計画を追認しているだけになります。
途中で反対したり、「その前提は違う」と伝えたりすることが重要です。Grill Meは人間の代わりに決めるSkillではなく、人間が決めるための質問役です。
`/code-review`は、レビュー対象を指定する
/code-reviewは、比較する基準点を必要とします。main、特定のコミット、HEAD~5など、どこからの差分を見るかを指定します。
また、未コミットの作業ツリーは対象になりません。実装した変更をコミットしてからレビューする必要があります。
仕様書が見つからない場合、Spec側は要件を勝手に推測せず、「仕様がない」と報告します。これは弱点ではなく、存在しない要求をAIが発明しないための安全策です。
AIの指摘は、そのまま証拠にはなりません。指摘された行、規約、仕様の箇所を人間が確認してから修正します。
作る前はGrill Me、作った後はcode-review、環境はdoctor
/grill-me、/code-review、/doctorは、確認する対象が違います。
/grill-me：作る前に、考えを質問で明確にする/code-review：作った後に、規約と仕様を分けて確認する/doctor：作業環境や設定の問題を診断する
AI開発で起きやすい失敗は、「曖昧な依頼のまま作り始めること」と「完成したコードを一つの視点だけで確認すること」です。
そのため、次の使い分けがわかりやすいです。
> 環境が怪しければdoctor。作る前はGrill Me。作った後はcode-review。
この3つを使い分けると、AIに丸投げするのではなく、環境・目的・成果物のそれぞれに人間の判断を残せます。
公式ページ：
Skillを増やせば必ず速くなるわけではありません。目的が明確な小さな修正までGrill Meにかけると、質問そのものが負担になる場合があります。
この記事の3つのSkillは、目的・環境・成果物を分担して確認します。/doctorで環境、/grill-meで目的、/code-reviewで完成物を見る流れです。
/grill-meは作る前だけでなく、開発途中で迷走したときにも使えます。時間がかかりすぎていると感じたら、いったん実装を止めて目的を整理するのがおすすめです。