# Grill: interrogate decisions

For /FD-grill or consequential uncertainty found during research/planning. Apply core rules. Use it to clarify needs or challenge an existing proposal.

## Establish boundaries

Read the idea, relevant code, task record, and settled decisions. Reuse project terminology; clarify ambiguity only when it affects a decision.

Sketch major decisions and dependencies. Resolve upstream choices first. Match depth to the problem; do not impose a question quota or import unrelated engineering concerns.

## Decision coverage and pacing

Track which consequential choices are verified facts, user-confirmed, explicitly delegated, open, or conditionally deferred. Repository evidence can establish facts, not silently choose user preferences. A broad answer or accepting one option does not delegate all remaining choices.

Before concluding, check that upstream goals, scope, observable acceptance, and consequential tradeoffs have an actual basis. For UI/UX, follow its fuller decision checklist and external-research gate. Do not invent a question quota, but do not treat a sparse exchange as agreement while decision categories remain open.

## One consequential question per round

1. Investigate relevant implementations, configuration, types, and documentation before asking about discoverable facts.
2. For consequential technical uncertainty unresolved locally, consult version-relevant official sources or comparable engineering examples. Explain applicability; user preferences do not require external proof.
3. Ask one consequential Chinese question in conversation, with meaningful choices when useful, a recommendation, and its cost; then wait for the answer. No particular question-card tool is required. Do not batch unresolved decisions or treat silence/default choices as an answer.
4. A recommendation may be a small experiment before deciding. State missing evidence instead of forcing certainty.
5. Update the decision and downstream impact from the answer. Use concrete scenarios to clarify material ambiguity; do not repeat already sufficient answers.
6. Keep each round short: at most a few brief context/rationale bullets before the question. Do not produce the full brief, plan, prototype, or a long decision essay until consequential choices are resolved. Provide a compact snapshot only when useful or requested.

Use a concise Chinese question structure when useful:

~~~text
正在决定什么：
已知依据与仍不确定的部分：
推荐选择及理由：
需要接受的代价：
本轮问题：
~~~

If the user delegates a choice, make a reasonable decision within authorization and record its rationale and cost. Acceptance of a recommendation settles that choice, not implementation approval.

## Test plausible failure

Choose scenarios relevant to the actual decision: partial failure, input boundaries, retries, data corruption, permissions, resources, or unavailable dependencies. Do not invent distributed scale, multi-tenancy, or cloud requirements for a local tool.

Before concluding a complex proposal, examine a credible failure after implementation, the most damaging mistaken assumption, observable warning signals, and a preventive check, mitigation, or rollback.

Analyze risks answered by evidence yourself. If user judgment is needed, keep asking one question per round rather than batching the failure analysis.

## Record and conclude

Record consequential questions, choices, reasons, evidence, accepted tradeoffs, unverified assumptions, and downstream effects. Distinguish open, decided, and conditionally deferred items; accepted risk is separate from whether a decision is settled.

Defer nonblocking items only with a reason they do not invalidate current work and a trigger to revisit. The user may pause and receive partial conclusions; label blockers clearly.

Conclude in Chinese when critical decisions are clear and remaining items do not invalidate implementation. Reuse effective decisions. For complex work use the same file in [task-record.md](task-record.md), rather than parallel decision logs or unsolicited global terminology edits.

If a conclusion changes an approved plan, record the affected revision and seek its confirmation before implementing it.