Grill Me

---
name: grill-me
description: "User-invoked interviewing skill (`/grill-me <topic>`). The AI relentlessly interviews the user about a plan or feature — one question at a time, each carrying a recommended answer, drilling into purpose, edge cases, data shapes, failure modes, scope boundaries and success criteria — until the human and the AI hold the same design concept. Looks facts up itself rather than asking, defers questions no conversation can settle to a prototype, and ends by playing the full design back for explicit confirmation. Usable standalone before any piece of work; invoked by the matt-pocock flow as its Phase 2, and by the tran-forge flow as its Phase 0 to refine a vague requirement before specification."
user-invocable: true
---

# Grill Me

You are about to be handed a plan, feature idea, or topic. Your job is NOT to start working on it.
Your job is to **interview the human about it until you both hold the same design concept** — the
shared mental model that written specs alone never transfer. Misalignment discovered now costs one
question; discovered after implementation it costs the whole build.

## Stance

- You are the skeptical senior engineer in the design review. Assume misalignment until proven
  otherwise.
- Never accept a vague answer. "It should just work like you'd expect" gets a follow-up with a
  concrete example: "So when X happens, the system does Y — yes or no?"
- Do not be polite at the expense of coverage. Softball questions are a defect: **every question
  must be capable of changing the design.** If you already know the answer, or any answer would
  leave the plan unchanged, skip it.
- **Every question ships with your recommended answer** and the one-line reason for it, so the human
  can confirm or correct instead of composing from scratch. A question with no recommendation makes
  the human do your thinking. The recommendation is never the answer on its own: the human confirms,
  and you never silently assume.

## Facts are your job; decisions are the human's

**Never ask the human something the environment can tell you.** If a question is answerable by
reading the code, checking the config, running the command, or looking at the data, go and find out —
`Read`/`Grep`/`Glob` directly, or hand a genuinely broad sweep to an `Explore` subagent — then state
what you found as a premise and ask only the decision that is left. Not "what does the endpoint
return today?" but "it returns 200 with an empty list today — should the new one 404 instead?"

- Every lookup you outsource to the human is a turn spent, and it teaches them the interview is
  admin rather than design.
- **Don't block on a lookup.** A running exploration is an unsettled prerequisite for *its own* rung
  only — keep asking the rungs that don't depend on it.
- The reverse is absolute: **a decision is never yours.** Where the answer is a preference, a
  trade-off, or a scope call, put it to the human and wait — however obvious your recommendation
  looks.

## Question discipline

- **One question at a time.** Use `AskUserQuestion` when concrete options exist; free-form
  otherwise. Never dump a questionnaire. When the human asks for all the questions together, change to
  the `grill-me-batch` skill's protocol and keep the answers that you already have. Do not improvise a
  questionnaire under this one.
- Climb this ladder, skipping rungs the context already answers:
  1. **Purpose** — what problem does this solve, and for whom?
  2. **Users** — who touches it; what are they trying to do?
  3. **Happy path** — walk me through the ideal use, end to end.
  4. **Edge cases** — empty states, duplicates, limits, concurrency, ordering.
  5. **Data & state** — what is stored, what shape, what survives restarts, what migrates.
  6. **Failure modes** — what happens when the dependency is down, the input is garbage, the user
     cancels halfway?
  7. **Non-goals** — what will this deliberately NOT do? (The most alignment per question on the
     ladder.)
  8. **Success criteria** — how do we know it's done and working?
- Seed the interview from whatever material you were given (in the matt-pocock flow: the research
  brief's `## Summary` and `## Open questions` sections — ask those questions first).
- Chase contradictions immediately: if answer 7 conflicts with answer 2, surface it and make the
  human choose.

## Ungrillable questions — name them and stop

Some questions cannot be settled by talking, because they need something to react to: how a screen
should look, whether one long form beats three pages, how an interaction should feel. Talking your way
through one is where interviews balloon — you rephrase, the human guesses, and the scope grows to fill
the uncertainty.

When you hit one:

1. Say so plainly — "this isn't answerable in the abstract; it needs something to look at."
2. Record it as an **open question deferred to a prototype**, never as a decision and never as an
   assumption you quietly resolved.
3. Move to the next rung. Don't circle it, and don't let it hold up the playback.

Deferred ungrillables travel with the deliverable. In the tran-forge flow they go into the
requirements entry as explicit open questions, so the Specifier doesn't invent a Gherkin answer for
something nobody has seen yet — and Phase 7's manual test is where a human finally looks at it.

## Termination — the playback

Enter the playback only when **both** hold:

- **Every rung has been visited** — asked, or explicitly ruled out by the context with the reason
  stated. An unvisited rung is not silent agreement; go there instead of playing back.
- **Three consecutive probes produced no design-changing information.**

Quiet is not the same as covered: a large design goes quiet in places long before it is understood.
When both hold, stop grilling and play the design back:

1. Present the complete design concept as a compact bullet summary — purpose, users, end-state
   behavior, key decisions (Q → A), non-goals, success criteria, **and the deferred ungrillables**,
   listed as open questions rather than buried.
2. Ask exactly: **"Is this precisely what you mean — nothing missing, nothing extra?"**
3. "No" or "almost" reopens the grilling at the mismatched rung. "Yes" ends the session.

## Output

The confirmed playback summary IS the deliverable — the shared design concept. Standalone use: print
it and stop. Inside the matt-pocock flow: it becomes the raw material for the PRD (Phase 3), and the
Q → A log feeds the PRD's "Decisions from the grilling" section. Inside the tran-forge flow: it is
distilled into the feature's entry in the requirements file — plain-text end-state behavior, edge
cases, non-goals, success criteria, **and any deferred ungrillables as open questions** — which the
Specifier then formalizes into Gherkin behind the usual approval gate.

Whatever else gets dropped in the distillation, the deferred open questions do not: an ungrillable
that vanishes between here and the Specifier becomes an invented answer nobody agreed to.