The Grill-Me Skill — Ahead of Plan Mode.

Plan mode in Claude Code is useful, but it has a failure mode: the plan is only as good as the decisions that went into it. If you enter plan mode with half-formed ideas and unresolved branches, you get a confident-looking plan built on guesses. /grill-me is the step that should come before plan mode.

You can download this skill from github.com/bogdanbaciu21/skills.

Credit where it's due: I did not invent /grill-me. Matt Pocock published a three-line version of this skill that went viral, and it's what put the idea on my radar. His core prompt:

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead.

Matt's framing — that this is rubber-ducking turned inside out, with the model asking the questions instead of being the silent duck — is the cleanest way I've heard it described. What follows is how I've extended it into a workflow that sits explicitly before plan mode.

What it is

A structured interview mode. The model plays experienced technical partner and walks every branch of a decision tree — one question at a time, waiting for each answer before moving on — until the two of you reach shared understanding.

The workflow

1. Get the subject. If the user hasn't already described a plan or feature, the skill asks what to grill on.
2. Map the decision tree. Identify the main branches that need resolution. Not all of them apply every time — include what's genuinely relevant:
   • Scope (what it does; what it explicitly does NOT do)
   • User-facing behavior
   • Data flow (inputs, outputs, storage)
   • Engine / calculation logic
   • Integration points
   • Error states and failure modes
   • Success criteria
3. Show the map before drilling in. "Here's what I want to work through. I'll go branch by branch."
4. Walk the tree systematically. Start with the most foundational branch — the one other decisions depend on. Ask one question at a time. For each, give your recommended answer based on what you know about the code. Probe until answers are specific: "Can you make that more concrete?" "What does that look like in practice?" "What's the edge case there?"
5. Track state. Know what's resolved and what's open. If an answer exposes a dependency on an unresolved branch, pause and resolve that first.
6. Synthesize. Once every branch is closed, produce a shared-understanding summary: what we're building, key decisions and rationale, open risks, suggested next step (usually /plan).

A short sample

Model: What does "done" look like from the user's perspective?

User: They can update the compensation rates in one place and the reports reflect it.

Model: One place in the UI, or one place in the data model?

User: One place in the UI backed by one canonical table.

Model: Good. If the report and the admin screen disagree, which one is the source of truth?

User: The admin screen writes to the canonical table. The report only reads.

Model: Then the next branch is migration and backfill. We should resolve that before plan mode.

Why it works where plan mode alone doesn't

Plan mode assumes the requirements are known and produces steps. Grill mode assumes the requirements are not known and produces a decision tree. Concretely: plan mode says "here are the steps to build a checkout flow," while grill mode asks "do we need guest checkout or require login?" The two skills compose: grill first, plan second.

There's a second effect: being interviewed by the model surfaces assumptions I didn't know I was making. The questions that have bitten me hardest are the ones that sound stupidly basic — "when the user does X, what does the UI actually show?" — and I realize I haven't thought about it. Better to find that out in a conversation than in a merge conflict.

When grill-then-plan beats plan mode alone

Grill mode is better when:

• there are real design branches still open
• success depends on edge-case behavior, not just happy-path steps
• the task crosses UI, data, and workflow boundaries
• the cost of being wrong is rework, not just a slower implementation

If the hard part is choosing, grill first. If the hard part is sequencing, plan mode is enough.

Tone rules

• Experienced technical partner, not adversary
• Short sentences, no filler
• Credit solid answers; flag gaps directly without drama
• Expose real decision points, not trivia
• Surface hidden assumptions: "You said X — does that assume Y is solved?"

When to skip it

Small, well-scoped tasks don't need grilling. A one-line bug fix doesn't warrant a decision tree. The heuristic: if the task would benefit from plan mode, it'll benefit more from grill-then-plan.

A reusable starter prompt

You are in grill mode. Do not plan implementation yet.
Interview me one question at a time until the requirements are specific enough for plan mode.
Start by showing the decision tree branches you think matter.
Push on ambiguities, edge cases, source of truth, success criteria, and failure modes.
When all major branches are resolved, summarize the decisions and tell me whether the task is ready for /plan.

Sources

• Matt Pocock, "It Ain't Broke: Why Software Fundamentals Matter More Than Ever", AI Engineer Code Summit, 2026 — where I first saw the skill on screen.
• Matt Pocock, "My 'Grill Me' Skill Went Viral" — the three-line original and the rubber-ducking framing.
• mattpocock/skills/grill-me/SKILL.md — install via npx skills@latest add mattpocock/skills/grill-me.