/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.
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 config gate, no setup.** `grill` reads nothing under `.task/` — `config.md` included — 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.

**Depth budget.** A typical grill is 3–7 questions. Depth over breadth — chase the one answer that would change everything, not ten that wouldn't. Stop as soon as the remaining forks would not change what gets captured.

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

Step 6: Print the ledger

Once the pre-mortem answer is folded in, 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, or a "we chose X over Y" that **more than one futu