/grill

name: grill
description: Interrogate a plan or decision one question at a time before capture, keeping a decision-plus-rationale ledger, then route to the right capture skill.
argument-hint: '[topic]'
disable-model-invocation: true
user-invocable: true

Pressure-test a plan, decision, or idea **before** it is frozen into an artifact. `grill` sits at the pipeline's first stage — "discuss freely in chat" — and gives it teeth: it interrogates the thinking one question at a time, records every answer as a decision with its rationale, closes with a pre-mortem, then hands off to the right capture skill. It writes **nothing**; its output is a hardened discussion plus a decision ledger that a `to-*` skill then serializes.

**Input:** `$ARGUMENTS` — optional. A topic or free-form context to grill (e.g. "the retry design", "whether to shard the queue"). Empty → grill the plan/decision being discussed in the current chat.

**No setup gate, no setup.** `grill` reads nothing under `.task/` — `.task/CLAUDE.md` included, so the platform never auto-loads it here — so it runs in a fresh, unconfigured project before any capture exists. Dialog mirrors the language of the chat; facts are looked up with plain tools (Read / Grep / Glob / Bash).

Step 1: Frame what is being grilled

State, in 1–3 sentences, the plan/decision/idea as you currently understand it — from `$ARGUMENTS` if given, else from the chat. This is the target the questions attack. Do not ask the user to confirm the framing with a separate prompt; the first question implicitly tests it.

Step 2: Resolve facts lazily, ask only decisions

Split what stands between you and the **next** question into two piles:

• **Facts** — anything the environment can answer: what a file does, whether a library is already a dependency, how an existing flow behaves. **Look these up yourself** with Read / Grep / Glob / Bash. Never ask the user a question the repo already answers.
• **Decisions** — genuine choices with trade-offs, no single right answer derivable from the environment. **These, and only these, are what you ask.**

Resolve facts **lazily** — only the ones that gate the next question, not everything up front — so the first question reaches the user fast. When several independent reads are needed for one question, batch them in parallel. If a supposed decision turns out to have a factual answer, resolve it silently and move on — don't burn a question on it.

**Nothing to grill.** If no genuine decision is left — every fork is already settled, or all of it is factual and answerable from the environment — **stop**. Do not manufacture questions to justify running. Say so plainly and redirect straight to the fitting capture skill (Step 7's routing), e.g. `→ Next: /task:to-plan — nothing left to interrogate; the approach is settled, capture it.`

Step 3: Grill — one question at a time

Walk the decision tree, **one `AskUserQuestion` per genuine fork** (convention (c)). Never batch. After each answer, new forks it exposes become later questions.

Each question:

• Poses a real decision with 2–4 concrete options.
• **Carries a recommendation.** The first chip is your recommended answer, labelled `… (Recommended)`. Each option's `description` states its consequence — what you get and what it costs — so the choice is informed, not blind.
• **Anti-sycophancy rule.** The recommendation is your honest read, not an echo of where the user seems to be leaning. When the user's implied leaning looks wrong, the recommended chip **must be the disagreement**, and its description must say why the leaning is the weaker call. Agreeing by reflex is a failure of this skill.

**Stopping rule.** Keep asking while an unanswered fork would change what gets captured; stop the moment none would. The question count is an outcome, not a target — a thin decision may settle in 2 questions, a spec-bound initiative may take 12. Depth over breadth: ask forks in descending blast radius — the answer that would change everything first — so stopping early loses the least.

**Continuation checkpoint.** When the capture-changing forks are resolved but genuine secondary forks remain, don't cut them off unilaterally — spend one `AskUserQuestion` on the fork about the grill itself: `Wrap up (Recommended)` vs. `Keep going`, the keep-going chip's description naming the remaining forks in one line. When nothing genuine remains, skip the checkpoint — it is a real path fork (convention (c)), not a ritual.

Step 4: Maintain the decision ledger

Maintain a ledger internally — one line per answered question, in the form `{the decision, at full specificity} — because {the load-bearing reason}`. After each answer, echo only the **new** line, not the whole ledger. Keep each line concrete enough that a reader who missed the chat understands both the choice and why it was made. The full block is printed once, in Step 6.

Step 5: Pre-mortem finale

Once the branches are resolved, ask **one** kill-shot question via `AskUserQuestion` before printing the ledger — pick whichever bites harder:

• "Fast-forward: this shipped and failed. What was the cause?" — options being the most plausible failure modes you see, recommended chip = the one you judge most likely.
• "What would make this whole thing unnecessary?" — options being the simpler alternatives or the do-nothing case.

Fold the answer into the ledger as a final decision line (the mitigation, or the confirmed reason to proceed anyway).

**Skip it when it earns nothing.** If the grill was thin enough that no plausible failure mode or simpler alternative would change the ledger, the pre-mortem is a manufactured question — Step 2's rule applies to it too. Go straight to Step 6.

Step 6: Print the ledger

Once the pre-mortem answer is folded in (or the pre-mortem was skipped), process the whole set of answers together and print the full ledger **as message text in your reply** — the whole block, once (convention (b)):

## Decis