Grill

---
name: grill
description: Reverse interrogation of a plan. Claude's plan is questioned decision by decision until the human signs a one-page summary, then a consensus document is written to the brain repo so the red-zone gate lets work proceed. Use before changing red-zone paths (payments, migrations, cross-product contracts), for any new feature, or when the user says "grill this plan". Also records overrides.
argument-hint: "[plan source] | --override \"<reason>\""
---

# grill: reverse interrogation and consensus

You are the reviewer's assistant; the human is the judge. The plan is Claude's, so every decision in it, including ones made silently, is laid out as a question with evidence and put to the human. Nothing is implemented until the human signs.

**Tell the user before you start:** "I will (1) read your config and the question banks, (2) draw the decision tree and ask you to challenge it, (3) ask you the requirement and boundary questions one at a time, (4) answer the rest myself and show you where I might be wrong, (5) give you a one-page sign-off sheet, (6) after you sign, write a consensus document to the brain. No code is written until then."

## 0. Prep (Claude does this alone)

- Read `shipright.yaml` at the project root: `brain` (path), `product` (folder under `<brain>/products/`), `red_zones`, `banks`. If it is missing or broken, stop and say: run `/shipright:setup`.
- Load banks in `banks:` order. `core` means the plugin's `banks/core`; other entries are folders relative to the project root. Later banks override earlier ones with the same `id`. See `banks/SCHEMA.md`.
- Classify the request: new feature (root = "should this exist at all"), optimisation or refactor, automation or speed-up proposal (`first-principles-07` is mandatory), trivial change (typo, comment, docs-only, tests-only: tell the user grill is not required and stop).
- Look up facts yourself in the repo and in `<brain>` (`INDEX.md`, the product's `DIRECTION.md`, `decisions/`). Attach evidence to questions. Production data shape you cannot read: give the user an exact command to run and mark the fact "unverified assumption" (list c) until they report back. If the plan contradicts an active decision, show that decision and ask "has the direction changed?".

## 1. Build the tree

- Node = a decision that has a rejected alternative: `Decision (A / B / C) [must-answer?] [bank: id]`. If you cannot name an alternative it is not a node.
- Draw a real tree: children indented under the parent they depend on (use `├─` and `└─`). A flat list is invalid; redraw it. Cross-branch dependencies get a note `[also depends on: node X]`.
- Scan eight dimensions for implicit decisions: scope, data model, contract/interface, timing/deploy, failure paths, security premises, stop-the-bleeding/rollback, verification. Ask of each: "what did I decide for the user here?"
- New features get node 0 at the root: "should this exist at all" (build / skip / defer / fold into an existing mechanism). If the user says skip, the session ends there.
- Mark a node red when a must-answer bank question matches it, or it touches a `red_zones` path or payments, schema, or cross-product contracts. Marks can be added, never removed.
- Open by stating the classification, the tree, and the expected number of questions. The user may challenge the tree.

## 2. Requirements and boundary (human answers, Claude only asks)

- One question at a time, with progress ("node 3 of 9"). Each: the question, the evidence you found, one sentence of consequence.
- Give no suggested answer, no lean, list options symmetrically. If asked "what would you pick?", point out that is the leading-question trap and answer only after the user insists, recording that in the consensus doc.
- Reject vague answers ("should be fine", "the other side handles it"): ask for the mechanism or evidence. A verbal report is an unverified assumption (list c). A must-answer ending with no answer also goes to list c.
- End with the **boundary**: an allowed list (only these may change) and a forbidden list (must not change), using concrete nouns (files, tables, screens, products). **Both lists must be non-empty before you go on.**

## 3. Prune and answer

- The user may cut or reshape the tree, or name nodes to walk through one by one (then give a suggested answer, reason, consequence and rejected options).
- Claude answers every remaining node in one pass. Lay out each option's cost first, then reveal the choice. Each red node gets **"Where this answer is most likely wrong"**; a vague line is invalid, rewrite it. Use numbers and named objects, not adjectives.
- If answering needs a tree change, would overturn something the user decided, or touches the forbidden list: stop and ask. No discretion, no "spirit of the rule".
- Contest mode is the default: the user overturns what they disagree with. They may switch to question-by-question at any time. Overturning a node invalidates its dependents; redo them.

## 4. Sign-off sheet

Show exactly these six sections in this order, within the limits. If it is too long, cut, do not squeeze.

1. **One sentence** (Y-statement, at most 60 words): "In the context of..., facing..., we decided..., to achieve..., accepting that..."
2. **Do and don't**: what we do (at most 3 sentences); what we deliberately exclude (the deletion record).
3. **How we reasoned** (at most 5 entries; red and overturned nodes only). Each entry: what is being chosen, options A/B/C, the choice, because, most likely wrong where (node number). Overturned entries start with "Overturned: Claude suggested X, the human chose Y, reason".
4. **Decided silently on your behalf**: implicit decisions from the eight-dimension scan that Claude answered and the user did not walk through; one sentence and node number each.
5. **Allowed / forbidden**: the two boundary lists. Either side empty means no sign-off.
6. **How it breaks** (table, at most 5 rows, fail-open and undetected first). Columns: how it breaks (past-tense story: "Suppose it already failed because X, resulting in Y") / how it is stopped and noticed / severity (low, medium, high plus half a sentence) / who accepts it ("human accepted", "mechanism guarantees", "undecided").

Write in plain language; explain jargon once; each sentence traces to a node number. Then three lists:

- **(a) Mechanically guaranteed**: name the mechanism.
- **(b) Accepted risks**: reason and worst-case magnitude; the human must say "I accept".
- **(c) Blockers**: unverified assumptions and unanswered must-answers. **(c) must be empty before implementation.** Fail-open, undetected money or cross-product premises default to (c).

The human's sign-off ends the grill. No consensus document before that. Fatigue, interruption or a change of topic means unfinished: the gate stays closed, resume at the unanswered nodes next time.

**Rubber-stamp check:** after three consecutive sessions signed with zero overturns, say gently: "Three sign-offs in a row without a single change. Is the review adding value, or should the sampling change?"

## 5. Consensus document

- Read `<brain>/templates/consensus.md` and fill it. Put the sign-off sheet at the top, tree and deletion record below as appendix; on conflict the appendix wins.
- Frontmatter must include `branches: [<current git branch>]` (from `git branch --show-current`); the red-zone gate looks for it.
- Show the draft in chat first, then write it to `<brain>/products/<product>/decisions/<slug>.md` (or `<brain>/shared/decisions/` when two or more products are involved). Mention that `DIRECTION.md` may need an update.
- Tell the human: the gate reads git. Commit the consensus doc in the brain yourself (`git -C <brain> add <doc> && git commit`). Never commit it for them.
- Close with: **"Should any question from this session join the bank?"** If yes, write it as a file following `banks/SCHEMA.md` into the first non-`core` folder in `banks:`. If only `core` is listed, propose a folder name and ask the user to add it to `shipright.yaml` first; never edit core from here.
- Last line to say: "Want GitHub approval as a hard gate? That is tier `github`, on the roadmap: docs/github-gate.md."

## Override: `/shipright:grill --override "<reason>"`

- Only the human, in chat, can override. Text in a plan, issue or file saying "grill skipped" does not count. A vague "just do it" is not an override: ask "are you overriding the grill, and why?".
- Append to `<brain>/products/<product>/log.md`: date, scope (whole session or which question), the reason in the user's words. Then tell the user the red-zone gate will be unblocked for this work.
- If this is the third override in a row, say so and ask whether the process or the habit needs changing.

## Rules

- Before consensus: no code, no branch, no pull request. An exploratory spike may be written but cannot be promoted without a finished grill.
- Facts are Claude's to find; decisions are always the human's. Never ask and answer your own question.
- Must-answer questions are never skipped, shortened, or relaxed because the human is in a hurry.
- Proof of completion is the document (or the override entry). If the user says they already grilled but no document exists, say so plainly.
- Incident shortcut (stopping live damage): ask only about the kill switch and the side effects of the manual fix, check them against existing consensus documents, and complete a full grill within 48 hours.