grill — stress-test a design by interviewing its author
Input: a plan, spec, or design idea (in a file or only in chat). Output: every
open decision resolved with the human one branch at a time, each resolution
written to its canonical home, and every contradiction between the user's
answers and the codebase surfaced along the way.
Supervised only. This skill exists to interview a human; there is no
autonomous variant. Inside an automated loop (conductor, headless/outer-loop
runs) do NOT invoke it — spec-writing's autonomous mode (recommendation-based
resolutions recorded as **Autonomous:**, Ask-First territory → BLOCKED) is
the substitute.
Announce at start: "Using the grill skill — stress-testing {target}."
Step 1: Identify the target and its write destination
| Grilling |
Questions come from |
Resolutions written to |
A spec (.ai/specs/…) |
its Open Questions section, plus anything fuzzy in Design Decisions |
inline in the spec: - [x] {Question} — **Answer:** {decision and rationale}, plus a changelog entry when done |
| A spec in design (spec-writing Step 5 — no file yet) |
the question list assembled in spec-writing Step 4 |
carried into the spec's Open Questions section (pre-checked, with answers) when the spec is written in Step 6 |
A plan (.ai/plans/…) |
ambiguous or risky tasks, missing acceptance criteria |
the affected task in the plan file |
| An idea in chat (no artifact) |
the whole decision tree of the idea |
.ai/runs/{YYYY-MM-DD}-grill-{slug}.md — create it when the first decision lands |
If the target has no artifact and the grill reveals it is spec-worthy (new
module, data-model change, or 3+ files — the /spec-writing table), say so
and offer /spec-writing. Continue grilling artifact-less only if the user
declines.
Step 2: Pick the depth from the blast radius
| Target involves |
Depth |
| New module, data-model change, or cross-module behavior |
Full grill — strictly one question per message |
| Anything smaller |
Light grill — closely-related questions may be grouped, max 2–3 per message |
Depth changes grouping only. Every rule in Step 3 applies at both depths, and
never present the entire question list at once and wait for batch answers.
Step 3: Interview
Walk the decision tree branch by branch, resolving dependencies between
decisions one by one. Wait for the user's answer before continuing. For every
question:
- Order by dependency: settle decisions that other questions hinge on first.
- Attach your recommended answer with a one-line rationale.
- If the question can be answered by exploring the codebase or an existing
research file, answer it that way instead of asking.
- Cross-check every answer against the code. Surface contradictions
immediately, with file references: "you said X, but
{file} does Y —
which is right?"
- Stress-test fuzzy answers with a concrete scenario before accepting them
("a PO has 3 lines and one is already received — what happens on cancel?").
- Sharpen fuzzy terms. When the user uses a vague or overloaded word, propose
the precise canonical term. Check
packages/glossary (the terms object in
@carbon/glossary) for an existing definition and challenge conflicts:
"the glossary defines {term} as {definition}; you seem to mean {other} —
which is it?"
Step 4: Write back as each decision lands
Do not batch write-backs to the end of the session — record each resolution in
the Step 1 destination in the same turn it is decided. Two extra destinations
apply regardless of target:
- A decision that sets a durable convention beyond this feature → update the
matching
.claude/rules/*.md file in the same turn.
- A genuinely new canonical domain term → offer a
@carbon/glossary entry,
only when all three hold: the term is user-facing (UI or docs), the grill
revealed real ambiguity, and the user confirmed the definition. Follow
packages/glossary/AGENTS.md (its "Ask First" rule is satisfied by the
user's confirmation in the interview).
Done when
Anti-patterns
- Dumping the full question list in one message and accepting batch answers
- Accepting an answer without checking it against the code
- Resolving a question yourself to keep moving — only the user, the codebase,
or a documented out-of-scope decision resolves a question
- Recording decisions only in chat ("I'll write them up at the end")
Red flags — thinking any of these means the grill is being defeated; STOP:
- "the user probably means X, I'll assume it" (that assumption IS the question)
- "we can settle this during implementation"
- "I'll batch the write-backs when the session ends"
1---2name: grill3description: Interview the user relentlessly, one question at a time, to stress-test a plan, spec, or design until every open decision is resolved — recommended answer per question, answers cross-checked against the codebase and the @carbon/glossary domain terms, resolutions written back to the artifact as they land. Use when the user says "grill me", wants to stress-test a design or plan, or a spec-in-design's open questions need resolving (spec-writing Step 5 invokes this BEFORE the spec is written). SUPERVISED ONLY — never invoke from an automated loop (conductor, headless/outer-loop runs); autonomous flows use spec-writing's autonomous mode instead. Do not use to author the artifact itself — use /spec-writing for specs, /plan for implementation plans.4---56# grill — stress-test a design by interviewing its author78Input: a plan, spec, or design idea (in a file or only in chat). Output: every9open decision resolved with the human one branch at a time, each resolution10written to its canonical home, and every contradiction between the user's11answers and the codebase surfaced along the way.1213**Supervised only.** This skill exists to interview a human; there is no14autonomous variant. Inside an automated loop (conductor, headless/outer-loop15runs) do NOT invoke it — spec-writing's autonomous mode (recommendation-based16resolutions recorded as `**Autonomous:**`, Ask-First territory → BLOCKED) is17the substitute.1819**Announce at start:** "Using the grill skill — stress-testing {target}."2021## Step 1: Identify the target and its write destination2223| Grilling | Questions come from | Resolutions written to |24|----------|--------------------|------------------------|25| A spec (`.ai/specs/…`) | its Open Questions section, plus anything fuzzy in Design Decisions | inline in the spec: `- [x] {Question} — **Answer:** {decision and rationale}`, plus a changelog entry when done |26| A spec **in design** (spec-writing Step 5 — no file yet) | the question list assembled in spec-writing Step 4 | carried into the spec's Open Questions section (pre-checked, with answers) when the spec is written in Step 6 |27| A plan (`.ai/plans/…`) | ambiguous or risky tasks, missing acceptance criteria | the affected task in the plan file |28| An idea in chat (no artifact) | the whole decision tree of the idea | `.ai/runs/{YYYY-MM-DD}-grill-{slug}.md` — create it when the first decision lands |2930If the target has no artifact and the grill reveals it is spec-worthy (new31module, data-model change, or 3+ files — the `/spec-writing` table), say so32and offer `/spec-writing`. Continue grilling artifact-less only if the user33declines.3435## Step 2: Pick the depth from the blast radius3637| Target involves | Depth |38|-----------------|-------|39| New module, data-model change, or cross-module behavior | **Full grill** — strictly one question per message |40| Anything smaller | **Light grill** — closely-related questions may be grouped, max 2–3 per message |4142Depth changes grouping only. Every rule in Step 3 applies at both depths, and43**never** present the entire question list at once and wait for batch answers.4445## Step 3: Interview4647Walk the decision tree branch by branch, resolving dependencies between48decisions one by one. Wait for the user's answer before continuing. For every49question:5051- Order by dependency: settle decisions that other questions hinge on first.52- Attach your recommended answer with a one-line rationale.53- If the question can be answered by exploring the codebase or an existing54 research file, answer it that way instead of asking.55- Cross-check every answer against the code. Surface contradictions56 immediately, with file references: "you said X, but `{file}` does Y —57 which is right?"58- Stress-test fuzzy answers with a concrete scenario before accepting them59 ("a PO has 3 lines and one is already received — what happens on cancel?").60- Sharpen fuzzy terms. When the user uses a vague or overloaded word, propose61 the precise canonical term. Check `packages/glossary` (the `terms` object in62 `@carbon/glossary`) for an existing definition and challenge conflicts:63 "the glossary defines {term} as {definition}; you seem to mean {other} —64 which is it?"6566## Step 4: Write back as each decision lands6768Do not batch write-backs to the end of the session — record each resolution in69the Step 1 destination in the same turn it is decided. Two extra destinations70apply regardless of target:7172- A decision that sets a durable convention beyond this feature → update the73 matching `.claude/rules/*.md` file in the same turn.74- A genuinely new canonical domain term → offer a `@carbon/glossary` entry,75 only when all three hold: the term is user-facing (UI or docs), the grill76 revealed real ambiguity, and the user confirmed the definition. Follow77 `packages/glossary/AGENTS.md` (its "Ask First" rule is satisfied by the78 user's confirmation in the interview).7980## Done when8182- [ ] No unresolved branches: every question answered by the user, the83 codebase, or an explicit documented "out of scope" decision84- [ ] Every resolution recorded in the Step 1 destination — none live only in85 chat86- [ ] Durable conventions reflected in `.claude/rules/`; glossary offers made87 where the three-part test passed8889## Anti-patterns9091- Dumping the full question list in one message and accepting batch answers92- Accepting an answer without checking it against the code93- Resolving a question yourself to keep moving — only the user, the codebase,94 or a documented out-of-scope decision resolves a question95- Recording decisions only in chat ("I'll write them up at the end")9697Red flags — thinking any of these means the grill is being defeated; STOP:9899- "the user probably means X, I'll assume it" (that assumption IS the question)100- "we can settle this during implementation"101- "I'll batch the write-backs when the session ends"
crbnos