Local-Cursor/internal/skills/builtin/fd-engineering/references/grill.md

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:

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

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