---
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)):

```
## Decision ledger

1. {the decision, at full specificity} — because {the load-bearing reason}
2. {…}
```

The ledger **is** the grill's output — print it, then go straight to Step 7 routing, no confirmation chip: every line restates a decision the user already made through the questions above.

grill writes nothing, so there is no file to guard and no "declined" state — an abandoned grill is simply one the user doesn't route onward. If the user wants a line changed, they say so in chat: correct it and reprint the ledger.

### Step 7: Route to the right capture skill

Diagnose what was actually grilled and close with the canonical footer (convention (a), flag-free) naming **exactly one** next skill plus a one-line reason. The tests below are **ordered — first match wins**; stop at the first one that holds:

1. **Cross-task technical anchors** — the ledger pins a protocol, a shared data shape's exact form, or a "we chose X over Y" that **more than one future task must honor identically**, and that a later session would plausibly re-derive differently. Each such line names a concrete artifact (a type, a format, a protocol, a boundary rule) **and** the alternative it beat → `→ Next: /task:to-spec — the ledger pins cross-task technical anchors; capture them as a spec.`
2. **An initiative whose technical shape was settled** — several tasks, and the ledger also fixes which components they build or change and what one hands another, without a rejected alternative to preserve → `→ Next: /task:to-architecture — a multi-task initiative with its technical shape decided; capture the roadmap together with its architecture.`
3. **An initiative that sprawled into several tasks** → `→ Next: /task:to-roadmap — this grew into a multi-task initiative; capture it as a roadmap.`
4. **A single implementable task, approach settled** → `→ Next: /task:to-plan — one task with the approach nailed down; capture Description + Plan.`
5. **A single task, approach still open** → `→ Next: /task:to-task — one task worth recording now; flesh out the plan later.`

**Test 1 is narrow on purpose.** Step 4 makes *every* ledger line read "{decision} — because {reason}", so the presence of reasoning is not the signal — reasoning that **binds work the ledger itself does not contain** is. One task's own internal reasoning belongs in that task's Description, not a spec: fall through to 4 or 5. Likewise a component layout or "item 2 hands item 4 an event" with no rejected alternative is technical shape, not an anchor: fall through to 2.

Pick the one that fits; state the reason in the same language as the dialog. Do not run the capture skill yourself — the footer is the handoff.

## Forbidden

- **Writing anything, anywhere** — no files, no edits, above all nothing under `.task/`. Serializing the ledger is the `to-*` skills' job; `grill` only hardens the discussion.
- **Reading or writing anything under `.task/`, `.task/CLAUDE.md` included** — no setup gate, no inline setup; `grill` runs before any setup exists and dialog mirrors the chat's language.
- **Batching questions** — one `AskUserQuestion` per fork, always. No multi-question rounds.
- **Acting on the grilled plan** — no implementing, refactoring, or "just fixing it" mid-grill. This skill interrogates; it does not execute.
- **Asking what the environment can answer** — resolve facts by looking them up; spend questions only on genuine decisions.
- **Reflexive agreement** — a recommendation that merely mirrors the user's leaning when that leaning is the weaker call violates the anti-sycophancy rule.