--- name: grilling description: > WellForge grilling — the one-question-at-a-time interview that walks an idea, spec or plan down its decision tree. Used by $wf-grill-me and $wf-spec --grill. Main loop only, never in a subagent. --- # Grilling — every load-bearing decision made out loud, by the person who owns it The default WellForge interview is deliberately cheap: batched questions, two rounds at most (`$wf-spec`, `$wf-new`). It closes the gaps the author *noticed*. What it cannot do is follow an answer — and the expensive defects start exactly there: the second question that only exists because of how the first was answered, and the gap nobody asked about that the author then filled with a guess phrased as a fact ([`self-critique`](../self-critique/SKILL.md): *assumption smuggled in*). Grilling is the other mode. **One question at a time, in dependency order, each with a recommendation, until no remaining question could change the artifact.** It spends the human's attention to buy decisions that are actually theirs, so it is opt-in: the user asks for it (`$wf-grill-me`, `$wf-spec --grill`), nothing turns it on by itself. ## The rules 1. **Read before you ask.** A question the repository can answer is not a question for the user. Neighbouring `specs/`, the ADR index in `AGENTS.md`, `CLAUDE.md`, the glossary, the code the idea touches — read them first, and report what you learned as a **finding** ("orders already carry a `tenant_id`; I am taking multi-tenancy as given"). The user corrects a wrong finding in one word; they should never have to dictate what is on disk. 2. **Map the tree before the first question.** Name the branches — the decisions this idea forces — and which depend on which. Show it in a few lines. It tells the user how much is coming, and it is what "done" is measured against. 3. **One question at a time.** Never a batch. Each answer prunes or reshapes what follows, and a batch asks questions the previous answer would have deleted. 4. **Parents before children.** Ask the decision other decisions hang on first. A leaf asked under an unresolved parent gets answered twice, or answered for a branch that is about to disappear. 5. **Every question carries your recommendation, and why.** Not a neutral menu: say which answer you would pick, the reason, and what gets more expensive if it turns out wrong. Use AskUserQuestion with the recommended option first when the answers can be enumerated; ask in plain text when they cannot. 6. **Only load-bearing questions.** The test: would the two most likely answers produce a different artifact — a different AC, non-goal, contract or task? If not, do not ask. Decide, and record it as an assumption the user can strike. 7. **Do not accept a non-answer.** "Fast", "the usual", "whatever is standard" gets one follow-up asking for the observable version. An answer that contradicts an earlier one, an ADR, or the code is said so at once, with both sides quoted — never smoothed over, never silently reconciled in favour of whichever came last. 8. **Stay on the artifact's side of the line.** Grilling a spec is about the WHAT and WHY: a technical decision the user volunteers is recorded verbatim as a constraint, not explored. Grilling a plan is about the HOW, and a question that reopens the WHAT is drift on the spec ([`spec-driven`](../spec-driven/SKILL.md)) — say so, do not relitigate it inside the plan. Relentless is about substance, not tone. Push on a vague answer; never on the person. ## When it stops - **The tree is resolved** — every branch on the map is closed, or - **nothing left is load-bearing** — every remaining question fails rule 6, or - **the user says stop.** Immediately, and without a parting question. Whatever is unresolved is listed as open, never guessed to make the ledger look finished. There is no question cap, so the cost stays visible instead: each time a branch closes, say so and say how many remain ("scope closed — 2 branches left: failure handling, permissions"). The ledger is **written to disk as each decision resolves** (below), so a long interview that gets compacted, or a session that ends early, keeps what it settled: decisions that exist only in scrollback are decisions that will be re-asked. Say so when a branch closes ("ledger saved — 6 decisions"); do not re-print the whole ledger each time. ## The decision ledger The output of a grilling session, and the only thing a later command should read from it. It is a **file**, not a message — a conversation is not something `$wf-orchestrate`, a subagent, or tomorrow's session can read: | What is being grilled | The ledger lives at | |---|---| | a free-form idea (no feature exists yet) | `.forge/grill/.md` — a short kebab-case slug of the topic | | an existing feature (`specs/NNN-slug/`) | `specs/NNN-slug/ledger.md` — a new dated section is appended if one exists | Create it when you show the decision map, and rewrite it every time a decision resolves. When a spec is written from a `.forge/grill/` ledger, the command that wrote the spec **moves** the ledger to `specs/NNN-slug/ledger.md`, so it travels with the feature and is reviewed with it. Nothing else belongs in `.forge/grill/`: a ledger still there is an idea nobody has turned into a spec yet. ``` --- topic: grilled: target: idea | specs/NNN-slug/spec.md | specs/NNN-slug/plan.md complete: false # true only when a stop condition other than "the user said stop" ended it --- ## Decision ledger — Decided (the user chose): - D1 — Delegated (the user deferred to the recommendation): - D4 — recommended because Found (read from the repo, not asked): - F1 — Assumed (not load-bearing; strike any that is wrong): - A1 Open (unresolved — each needs an owner): - O1 — owner: ``` With `--docs` ([`domain-modeling`](../domain-modeling/SKILL.md)) the ledger gains two sections, and they are the only ones that describe something already written or about to be: ``` Terms (written to the glossary during the session): - T1 **** — [(delegated)] ADR candidates (a decision with a rejected alternative — offered, not yet written): - R1 — rejected: ``` **Decided and Delegated are different, and the difference is the point.** "You pick" is an honest answer, and it is not the same as the user having an opinion. A delegated decision is the first place to look when the feature turns out wrong, so it is never recorded as the user's choice. **How a ledger is consumed** — the same way by every reader (`$wf-spec`, the `wf-product-owner` agent, `$wf-orchestrate`): - **Decided** and **Found** are inputs. They are not reopened and not re-asked. - **Delegated** is used, and stays visibly delegated: where it lands in the artifact it is marked `(delegated — ledger D4)`, never written as though the user chose it. - **Assumed** is carried as an assumption the user may still strike. - **Open** becomes the artifact's `## Open questions`, owners kept. A technical decision the user volunteered goes verbatim under `## Constraints`. - `complete: false` means branches were left unvisited. The reader says so and treats the missing branches as open questions — it does not quietly finish the interview by guessing. `$wf-grill-me` ends by printing the ledger's path and the exact next command. ## Grilling with docs Plain grilling reads the glossary and the ADR index and leaves them as it found them. With `--docs` the session also **maintains** them, per the [`domain-modeling`](../domain-modeling/SKILL.md) skill: - **Language is challenged as it is used.** The user says a word the glossary defines differently, or uses two words for what looks like one concept: that is the next question, asked at once, with both usages quoted. - **A new term is stress-tested before it is written** — the boundary, identity, cardinality, time and absence probes. A scenario the definition cannot answer is the next question, not a gap you close yourself. - **The glossary is written as each term resolves**, not at the end, so it survives a session that is cut short. - **Decisions with a rejected alternative are collected as ADR candidates** and offered to the `wf-adr-writer` agent when the session closes. Never written inline. The eight rules and the stop conditions are unchanged; `--docs` adds what is written, not how questions are asked. ## Where it does not run - **Never in a subagent.** Agents cannot reach the user, so a "grilling" agent would be answering its own questions. The product-owner and architect return their open questions to the caller, as before. - **Never in `$wf-orchestrate`**, which batches open questions into one round by design — an orchestrated run that stops to interview is no longer orchestrated. Grill first, then hand the ledger over: `$wf-orchestrate --ledger `. - **Not at the `spike` tier.** A spike prefers a recorded assumption to a question ([`rigor-tiers`](../rigor-tiers/SKILL.md)). A user may still run `$wf-grill-me` before a spike; nothing in the spike itself starts one. ## What this is NOT - **Not approval.** A fully grilled spec is still `status: draft`. The ledger sets no status and checks no box; the human gate that follows runs exactly as before. - **Not a substitute for self-critique or review.** It removes unasked questions. It does not catch an unverifiable AC written from a perfectly good answer. - **Not design by interrogation.** You bring a recommendation to every question (rule 5). An interviewer with no opinion has moved the whole job onto the user. - **Not a way to edit an approved artifact.** Grilling something already approved produces proposed amendments, routed like any other drift. Related: [`spec-driven`](../spec-driven/SKILL.md) (the artifacts, the WHAT/HOW line and the drift rule), [`self-critique`](../self-critique/SKILL.md) (the smuggled-assumption failure this prevents upstream), [`rigor-tiers`](../rigor-tiers/SKILL.md) (why a spike does not interview), [`domain-modeling`](../domain-modeling/SKILL.md) (what `--docs` maintains).