grill-change

name	grill-change
description	Use when a stakeholder request is rough, ambiguous, or underspecified and needs clarification before planning, writing a spec, or creating issues.
disable-model-invocation	true

Grill Change

Purpose

Clarify a stakeholder request before any spec, issue plan, or implementation work starts. The output is an agreement record for a follow-up synthesis workflow; it is not an implementation plan.

Operating Rules

1. Ask one focused question, then wait for the user's answer.
2. Include a recommended answer with the question and explain why that answer is safest for the project.
3. Inspect relevant local specs, ADRs, docs, fixtures, and code before asking questions that local context can answer.
4. Challenge vague terms, overloaded words, and claims that conflict with repository evidence.
5. Prefer concrete examples, edge cases, and tradeoff choices over broad brainstorming.
6. Keep implementation details provisional until the product intent and non-goals are settled.
7. Capture durable terms and hard-to-reverse decisions in the agreement record when they crystallize.
8. Do not create issue lists, edit files, or start implementation during the grill.

Question Format

Use this shape for each question:

Question: <one decision or missing fact> Recommended answer: <the default direction you would choose> Why: <short reason based on product intent, safety, contracts, or repo evidence>

Design-it-Twice

For a hard-to-reverse choice, present it as a Design-it-Twice question: sketch two genuinely different paths before recommending one.

Path A: <approach> - interface: <the shape callers see>; risks: <what could go wrong>. Path B: <a genuinely different approach> - interface: <the shape callers see>; risks: <what could go wrong>. Recommendation: <the path you would choose and why>.

Do not offer two variations of the same path. Reserve this form for choices that are expensive to change later; a routine choice needs one recommended answer, not two paths.

ADR Candidates

Capture a decision as an ADR candidate when it is hard to reverse, surprising without context, or carries real trade-offs. Record the decision, the alternatives considered, and the reason as an agreement-record note only. Do not write an ADR file during the grill; synthesis persists it after approval.

Decision Checks

Before ending the grill, confirm:

• the problem in the stakeholder's terms
• the desired outcome
• explicit non-goals
• product intent and why the change matters
• tradeoff direction for ambiguous implementation choices
• user-visible behavior changes
• compatibility and migration expectations
• durable terminology and hard-to-reverse decisions
• safety and privacy constraints
• unresolved unknowns, if any

Output

When the user agrees the grill is complete, return:

• Problem
• Intent
• Non-goals
• Decisions made
• Durable terms and hard-to-reverse decisions
• Decision rules for implementation tradeoffs
• ADR candidates that meet the threshold
• Open questions or risks
• Confirmation that approving this record authorizes the derived synthesis and its bounded persistence

On Approval

Approving the completed agreement record automatically starts the synthesis step; no second command or approval is needed to begin it. That same approval authorizes one bounded local persistence of the derived spec candidate, issue briefs, ledger, glossary, and qualifying ADRs. It authorizes persistence only: it does not authorize implementation, and it does not authorize persisting anything the agreement record did not decide.

Safety

• Do not upload source code.
• Do not read or print secrets.
• Do not ask for credentials, environment values, production data, or private endpoints.
• Do not propose bypassPermissions, tool pre-approval, dependency auto-installation, hosted execution, or remote MCP behavior.
• Do not write files, create issues, commit changes, or run implementation commands during the grill.