Workflow Grilling

---
name: workflow-grilling
description: >
  Interview the user about a plan, decision, or idea one question at a time
  until you agree. Use when "grill me", "stress-test this plan", "interview me
  about this", "poke holes in this", "challenge my thinking", or before a
  non-trivial design.
license: MIT
effort: high
---

# Grilling

**Degree of freedom: MIXED.** Which branch to walk and how hard to challenge
`[HIGH freedom]`; one-question-at-a-time, recommend-an-answer, and
no-act-until-confirmed `[LOW freedom — run exactly]`.

> The most common failure mode in software work is misalignment: the agent builds
> what it *thinks* was asked. A grilling session closes that gap before any work
> starts. Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT).

Interview the user relentlessly about every aspect of the plan, decision, or idea
until you reach a shared understanding. Walk down each branch of the decision
tree, resolving dependencies between decisions one by one.

## How to reason

1. **Surface** — what decision or vague term is actually in play?
2. **Depend** — which upstream choice must land before this one?
3. **Recommend** — your answer and why, in one sentence
4. **Confirm** — wait; log the user's words, not yours

## Worked example

> **Surface:** "add AI chat to the dashboard" — "AI" and "dashboard" are both overloaded.
> **Depend:** audience (internal ops vs customers) gates model, retention, and auth.
> **Recommend:** internal ops assistant on existing `/dashboard` — cheapest test of the idea.
> **Confirm:** user picks customers instead; log that, then ask the next downstream (retention vs ephemeral).

## Self-critique before reporting

- **One question** — the last turn asked exactly one thing
- **Recommendation present** — every question included a default the user can accept
- **Facts looked up** — nothing askable from the repo was asked
- **Right owner** — session over → `design-prd` / `workflow-spec-tdd` / a `plan-*`; do not start building here

## Rules of the session  [LOW freedom — run exactly]

1. **One question at a time.** Ask a single question, then wait for the answer
   before continuing. Asking multiple questions at once is bewildering.
2. **Recommend an answer with every question.** State your recommended answer and
   why, so the user can accept it with a single word or push back.
3. **Facts are yours; decisions are theirs.** If a *fact* can be found by
   exploring the environment (filesystem, git history, docs, running commands),
   look it up instead of asking. *Decisions* belong to the user — put each one to
   them and wait. Before the first question, read the relevant sources broadly —
   repo, docs, git history, tickets — so the first question is already a
   decision, not a fact.
4. **Resolve dependencies in order.** When one decision hinges on another,
   surface the upstream decision first.
5. **Challenge vague terms.** When the user uses an overloaded or fuzzy word,
   propose a precise one (see `docs-domain-modeling` when the vocabulary itself needs
   fixing).
6. **Do not act until confirmed.** No edits, no scaffolding, no "getting a head
   start". The session ends when the user confirms shared understanding — then
   summarize the decisions made and hand off to the appropriate skill
   (`workflow-spec-tdd`, `design-prd`, `plan-*`).

## Output  [LOW freedom — run exactly]

Close the session with a compact decision log: each decision on one line, in the
user's confirmed vocabulary. This log is the input to the spec or plan that
follows — offer to carry it into `design-prd` or `/plan-mode`.