db73cf5a39
Includes the current working directory changes. Historical commits and release binaries are excluded to limit Gitea storage. Source base: d7515973fbfd6dd2001fa156c483455b8081c7cb
55 lines
4.2 KiB
Markdown
55 lines
4.2 KiB
Markdown
# 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.
|