| name | grilling-plan |
| description | Interview the user relentlessly to stress-test a plan or design BEFORE building, one question at a time. Use when the user wants to grill / pressure-test a plan, or before a change that touches fleet-shared resources (template/, _shared/, a new hook/lint rule/check). |
grilling-plan
The proactive complement to plan-review-nudge (the after-plan gate). Interview
the user relentlessly about every branch of the design tree until you reach
shared understanding — then the plan is ready to land.
1. Resolve the deterministic questions first
Before asking the user anything, answer every question the codebase already
answers — this is the code-first-then-ai discipline applied to design. If the
change proposes a NEW enforcement surface (hook, lint rule, check, skill, agent),
run the inventory and compare:
node scripts/fleet/codify-scan/inventory.mts
It emits the authoritative set of existing hooks / lint rules / checks / docs.
If the thing you'd build already exists, the answer is "extend it", not "add one"
— don't ask the user a question grep or the inventory settles. Read the
relevant files in place. Only what the codebase cannot answer goes to the user.
2. Interview one question at a time
Ask the residue — the design-intent questions no script resolves: trade-off
framing, naming, cascade blast-radius, the reversal condition. Rules:
- One question at a time. Wait for the answer before the next. Multiple
questions at once is bewildering.
- Every question carries your recommended answer and the reason, so the user
can accept with one word.
- Walk the tree in dependency order — resolve a decision its children depend on
before descending.
- If a later answer can be derived from an earlier one, derive it; don't re-ask.
3. Gate before landing
A fleet-shared change is settled only when the plan has the shape
plan-review-nudge checks for:
- Numbered steps, each naming the real files + rules it touches.
- The final name / schema shape decided up front (a name that will cascade must
not churn across commits).
- A second-opinion invite when the plan edits a fleet-shared resource
(
CLAUDE.md, template/, .claude/hooks/, _shared/).
Completion criterion
Every design-tree branch is resolved (by the codebase or by the user), the plan
names its files + rules in numbered steps, the cascaded names are settled, and —
for a fleet-shared change — a second opinion has been invited. Then write the plan
to .claude/plans/<name>.md and execute.
