grill-the-plan

name	grill-the-plan
description	Run BEFORE building anything from a vague, large, or freshly-stated feature ask — the moment the user says "plan this", "before we build", "grill me", "stress-test this idea", "help me think this through", or hands over a one-paragraph description of multi-file work. Use even if the ask looks clear enough to start coding — "clear enough" is exactly the state this interview exists to test, and in this multi-agent repo an unexamined plan burns worktrees, GPU slots, and sibling sessions' time. The output is a de-risked plan plus an explicit assumptions register, produced through a one-question-at-a-time interview. Slash alias: /grill-the-plan.
metadata	{"short-description":"One-question-at-a-time adversarial interview: vague ask -> de-risked plan + assumptions register"}

Grill the plan (adversarial requirement interview)

Why this exists

Most expensive false starts in this repo trace back to a constraint nobody stated: an eval that was supposed to be pre-registered, a branch a live pod was still pushing to, a "small" change that crossed a measurement-contract gate. An interview before the first file edit is the cheapest place to catch these. This loop catches unstated constraints; it does not guarantee the plan is right.

The interview loop

1. Split facts from decisions. Before asking anything, list what you can settle yourself by reading the codebase (file layout, existing seams, what CI gates apply, whether a tool already exists). Go look those up — never ask the user a question grep can answer. What remains are decisions, and decisions belong to the user.
2. Ask exactly ONE question per turn. Pick the question whose answer most reshapes the plan (scope boundary > success criterion > edge case > naming). Batching questions produces shallow answers; one at a time forces real ones.
3. Attach your recommended answer to every question. State it and why in one or two lines. The user can accept with a single word, which keeps the loop fast, and your recommendation exposes your current model for correction.
4. Hunt deliberately, in this order:
   • unstated constraints (repo gates, no-overclaim rules, live evidence branches, GPU/box contention — see repo-factory-router for routing);
   • edge cases (empty input, concurrent session, partial failure, re-run);
   • success criteria (what command, run by whom, proves this worked? — this later feeds verification-recipe-runner);
   • non-goals (what will we explicitly NOT do, so scope cannot creep back).
5. Walk each branch of the design to a leaf. When an answer opens a sub-decision, follow it down before moving sideways; note deferred branches so none are silently dropped.
6. Stop when answers stabilise. Two consecutive questions that only confirm what you already believed means the interview has converged. Do not pad the interview to look thorough.
7. Emit two artifacts in the conversation (or via /to-spec if the user wants a durable document):
   • De-risked plan — numbered steps, each with the check that proves it done.
   • Assumptions register — every load-bearing assumption you could NOT verify, each marked confirmed-by-user, inferred-from-code, or open. open items are risks, and the user must see them before work starts.
8. Get explicit confirmation ("shared understanding reached — proceed?") before any file is touched. Silence is not confirmation.

Composition

• Feed the result to /to-spec for a durable spec, then /to-tickets to slice it into work items.
• If the interview reveals the map itself is unknown (multi-session scale, "where do we even start"), switch to /wayfinder instead of forcing a plan.
• If a question is about how a recurring repo task is normally shaped (evals, ledger rows, manifests), consult task-blueprint before asking the user.

Do not

• Do not ask two questions in one message, ever.
• Do not ask the user for facts the codebase can answer — look them up.
• Do not start implementing "just the obvious part" mid-interview; the obvious part is where the unstated constraint usually lives.
• Do not present the plan as validated or risk-free; it is de-risked to the depth of the questions asked, no further. The assumptions register is the honest boundary of that depth.
• Do not skip the loop because the user sounds confident — confidence in the ask is independent of completeness of the ask.
• Do not answer your own interview questions to keep momentum; a self-answered grilling has stopped being one.

Method adapted from mattpocock/skills skills/engineering/grilling/SKILL.md, skills/productivity/grill-me/SKILL.md, and skills/productivity/grill-with-docs/SKILL.md (MIT) — see THIRD_PARTY_NOTICES.md.