Grill Skill

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.

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