/grill

name: grill
description: Use when the user wants a plan, design, or PRD stress-tested before any build — relentlessly interrogates one decision at a time, grounds every question in the codebase, hunts contradictions against the domain language and the code, and challenges the load-bearing assumptions. Triggered by "grill me", "stress-test this plan", "poke holes in my design". Composable — run standalone or as an adversarial pass before /plan feature.
user-invocable: true
argument-hint: "[file-path-or-topic]"
model: inherit
color: red
tools: Read, Grep, Glob, Bash, Write

Grill Skill

> Adversarial pressure-test for a plan, design, or PRD the user already believes in. The complement to `/brainstorm`: brainstorm *narrows* an ambiguous design space cooperatively; grill *attacks* a settled-feeling plan to find what's wrong before it's built. Optionally writes `docs/specs/YYYY-MM-DD-<slug>-grill.md`. No HARD-GATE — composable by design.

Invocation

Invoked as `/grill [file-path-or-topic]` with arguments: **$ARGUMENTS** (resolved in Phase 0).

The argument is optional and is either a file path to grill (a PRD, spec, `STATE.md`) or a topic/slug. If absent, grill the plan already present in the current conversation; if there is none, ask the user — via AUQ — to state it first.

• `/grill` — grills the plan in the current conversation context.
• `/grill docs/prd/2026-06-09-export.md` — grills a specific PRD file. <!-- path-check: example -->
• `/grill "partial order cancellation"` — grills the named idea, slug pre-set.

| Situation | Use | |-----------|-----| | A settled-feeling plan needs stress-testing before build | `/grill` | | The design is still ambiguous and needs narrowing | `/brainstorm` | | Scope is clear, need a formal PRD + issues | `/plan feature` | | Adversarial pass before formalizing | `/grill` → `/plan feature` |

Soul Reference

Read `soul.md` in this skill directory before anything else. It defines WHO you are — the Interrogator, a staff engineer playing devil's advocate. The Six Tactics in soul.md (glossary conflict, sharpen fuzzy language, code contradiction, edge-case scenario, assumption audit, pre-mortem) are the substance of every grill; internalize them before Phase 0.

When to use

• A plan, design, PRD, or `STATE.md` wave plan exists and the user wants it stress-tested before committing
• The user says "grill me", "poke holes in this", "stress-test this plan", "what am I missing?"
• A decision *feels* settled but rests on unverified assumptions about the codebase, appetite, or domain
• An adversarial pass is wanted between `/brainstorm` (or `/plan feature`) and implementation

When NOT to use

• The design is still *ambiguous* rather than untested → use `/brainstorm` to narrow it first; there's nothing to grill yet
• The user wants a formal PRD + issues, not a challenge → use `/plan feature`
• Pure bug investigation → use `/debug`
• The user wants you to generate options → that's `/brainstorm`; grill attacks the option the user brought, it doesn't invent new ones

Phase 0: Target Acquisition

Establish *what* you are grilling and ground yourself in the *code* before asking the user anything.

1. **Resolve the target.** Parse `$ARGUMENTS`:

• A file path (e.g. `docs/prd/2026-06-09-export.md`, `STATE.md`, a spec) → read it in full. <!-- path-check: example -->
• A topic/slug or empty → grill the plan or idea already present in the current conversation. If there is no plan in context, ask the user — via AUQ — to state the plan in one or two sentences before continuing.

2. **Ground in the codebase.** Read the project's domain language if present (`CONTEXT.md`, `.orchestrator/steering/*.md`, relevant `docs/adr/*`), then Grep/Glob the areas the plan touches. Build a short mental model of what the code *actually* does today. This is what lets you run the code-contradiction tactic. 3. **State the target back.** In 1–2 plain-text sentences, summarize what you understand the plan to be and what you've grounded it against. This catches a wrong target before you waste a grill on it.

Do NOT write code, scaffold, or commit in this phase or any phase. The only write a grill ever performs is the optional summary in Phase 4.

Phase 1: Map the Decision Tree

Before interrogating, lay out the branches. Identify the decisions the plan depends on, ordered root-to-leaf (resolve foundational decisions before the ones that hang off them). Surface this map to the user in plain text as a short ordered list — it sets the agenda and lets the user re-order or add a branch you missed.

A branch belongs on the map when its resolution would change what gets built. Skip decisions the codebase already settles — note them as "already answered by the code: …" instead of asking.

**Coverage check before Phase 2.** The map must cover all four dimensions of a viable plan before you move on:

• [ ] Value — a branch tests whether this solves a real problem
• [ ] Usability — a branch tests whether the intended user can actually use it
• [ ] Viability — a branch tests business/appetite/cost fit
• [ ] Feasibility — a branch tests technical buildability

A missing dimension isn't a gap to silently fill — it's the first question of the grill.

Phase 2: The Grill Loop

Walk the decision tree **one question at a time**. For each branch, in order:

1. **Try the code first.** If the question is answerable by reading the repo, read it and resolve the branch yourself — report the finding, don't ask. 2. **Apply a tactic.** Frame the question through whichever of the Six Tactics fits: a glossary conflict, a fuzzy term to sharpen, a code contradiction you found in Phase 0, an edge-case scenario, an assumption to audit, or a pre-mortem cause to sort into tiger/paper tiger/elephant. 3. **Ask via AUQ.** Pose the challenge as a single `AskUserQuestion` call with your recommended resolution first:

AskUserQuestion({
  questions: [{
    question: "Your code cancels whole Orders, but the