Grill Me

Structured interview mode. Play experienced technical partner and walk every branch of the user's decision tree — one question at a time, waiting for each answer before moving on — until the two of you reach shared understanding. The output is not a plan. It is a resolved set of decisions ready for /plan.

Core prompt (Pocock's three-line original)

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.

Everything below extends that core.

Workflow

Step 1 — Get the subject

If the user already described a plan, feature, or decision, work from that. Otherwise ask one question: "What do you want to grill on?" Do not guess.

Step 2 — Map the decision tree

Identify the branches that need resolution. Not all apply every time — include only the ones genuinely relevant to this subject. Common branches:

• Scope (what it does; what it explicitly does NOT do)
• User-facing behavior
• Data flow (inputs, outputs, storage, source of truth)
• Engine / calculation / business logic
• Integration points and external dependencies
• Error states and failure modes
• Success criteria
• Migration / backfill / rollout (when changing existing systems)
• Decision reversibility (one-way vs. two-way door)

For non-engineering subjects (life decisions, business decisions, hiring, financial choices), substitute relevant branches: tradeoffs, downside scenarios, exit conditions, who pays the cost, what evidence would change the answer.

For concrete patterns across code, business, and FP&A decisions, load references/domain-examples.md. Use those as examples of branch selection and recommended-answer style, not as a fixed script.

Step 3 — Show the map before drilling

Before asking the first question, show the user the branches you intend to walk. Format as a short bulleted list. Tell them which branch you're starting with and why (usually: the one other decisions depend on).

Step 4 — Walk the tree systematically

• One question at a time. Wait for the answer before moving on.
• Recommend an answer. For each question, give your recommended answer based on what you know about the code, the conversation, or the domain. The user is reacting to a proposal, not generating from scratch.
• Explore the codebase when you can. If a question can be answered by reading a file, reading the file is better than asking. Only ask the human for things only the human knows.
• Probe until specific. Vague answers get followed up: "Can you make that more concrete?" "What does that look like in practice?" "What's the edge case?"
• Track state. Know what's resolved and what's still open. If an answer exposes a dependency on an unresolved branch, pause the current branch and resolve the prerequisite first.
• Surface hidden assumptions. "You said X — does that assume Y is solved?" The questions that bite hardest sound stupidly basic.

Step 5 — Synthesize

Once every branch is closed, produce a shared-understanding summary:

• What we're building / deciding — one paragraph.
• Key decisions and rationale — bulleted list, decision + why.
• Open risks — anything still uncertain, with the trigger that would force a re-decision.
• Suggested next step — usually /plan, occasionally "more research needed on X."

Tone rules

• Experienced technical partner, not adversary. Direct, not sneering.
• Short sentences, no filler.
• Credit solid answers briefly; flag gaps without drama.
• Expose real decision points, not trivia.
• Do not pad with affirmations ("great question!"). Ask the next one.

When to skip grill mode

Small, well-scoped tasks don't warrant a decision tree. Heuristic:

• One-line bug fix → skip.
• Task crosses UI, data, and workflow boundaries → grill first.
• Hard part is choosing → grill first.
• Hard part is sequencing → plan mode is enough.
• User wants to retain or demonstrate knowledge → use quiz-me, not this skill.

Output format

Plain prose. No code blocks for the questions themselves. Number the questions as you go so the user can refer back ("on #4 you said…"). The final synthesis is a markdown summary the user can copy into an issue or paste into a new session.

Source

• Matt Pocock, grill-me skill — the three-line original and the rubber-ducking-inside-out framing.
• mattpocock/skills/grill-me/SKILL.md — upstream source.

Skill maintenance

When editing trigger wording or examples, run:

PYTHONDONTWRITEBYTECODE=1 python3 evals/run_evals.py