Grill with tree

Grill with Tree

Turn ambiguity into explicit, evidence-backed decisions and then into an implementation-ready brief.

Keep this workflow read-only with respect to implementation. Inspect source material freely, and write only decision-state or brief documents unless the user separately authorizes implementation.

Core rules

• Organize the interview by decisions, not implementation tasks.
• Inspect code, documentation, history, configuration, and other available evidence before asking anything locally discoverable.
• Ask only material questions. Different answers must change observable behavior, an interface or architecture contract, risk, reversibility, compatibility, rollout, or delivery scope.
• Ask exactly one unresolved question at a time. If the user answers several decisions voluntarily, record all of them.
• Include a recommended answer, the reason, and the important tradeoff with every question.
• Distinguish known facts, assumptions, recommendations, and user decisions.
• Add child nodes only when an answer exposes a new material choice. Use cross-links instead of duplicating a decision shared by several branches.
• Reopen earlier nodes when new evidence or a later answer invalidates them.
• Never confuse a ready plan with authorization to implement it.

Question format

Use stable node IDs such as D1, D1.1, and D2.

Decision D<n>: <one material question>

Why this matters: <one concise consequence>
Recommendation: <preferred answer and reason>

Options:
A. <option and main tradeoff>
B. <option and main tradeoff>
C. <optional third option>

After the answer, update the affected branch. Show the changed branch and the next open node; show the full tree only when it materially helps or the user asks.

Use these node states:

• open: requires a decision
• decided: explicitly settled
• inferred: settled from evidence; identify the evidence
• deferred: intentionally postponed with an owner or trigger
• blocked: cannot be resolved without missing authority or information

Workflow

1. Inspect the available sources and summarize the goal, affected surface, known facts, constraints, and non-goals.
2. Seed the smallest useful set of root decisions and show the initial tree.
3. Walk the highest-impact unresolved branch. Prefer prerequisite decisions before dependent ones.
4. After every answer, audit consequences across the relevant dimensions:
   • observable behavior and failure paths;
   • lifecycle, state ownership, and data flow;
   • interfaces and cross-system contracts;
   • compatibility, migration, security, privacy, and operations;
   • rollout, recovery, and verification.
5. Challenge contradictions, optimistic assumptions, missing failure modes, and decisions that move complexity elsewhere.
6. Before closing, map every requirement to a resolved decision, test the combined design with counterexamples, and list every remaining assumption.
7. Read assets/decision-tree-brief.md and use it to produce the final brief. Omit sections that are genuinely irrelevant; do not leave silent gaps.
8. Derive implementation tasks only after the decisions are settled.

Completion gate

Do not mark the brief ready for implementation until:

• the desired outcome and measurable success criteria are explicit;
• scope, non-goals, and constraints are explicit;
• every material behavior or contract is resolved or visibly deferred;
• ownership, failure handling, compatibility, rollout, and recovery are covered when relevant;
• acceptance criteria and verification are actionable;
• remaining risks and open items have an owner, trigger, or default;
• the execution graph respects real dependencies and shared-write boundaries.

Task decomposition

Keep coupled changes together. Do not target an arbitrary task count.

For every task, record:

• goal and deliverable;
• dependencies and parallel-safe peers;
• exclusive write ownership;
• settled contracts it must preserve;
• forbidden scope;
• acceptance criteria;
• tests or other verification.

Reserve shared-file changes, cross-task integration, and final validation for one explicit owner.

Multi-agent handoff

When the execution graph contains genuinely independent tasks, end with a ready-to-copy handoff:

Use $multi-agent to implement this brief. Treat the Locked Contracts as fixed.
Follow the task dependencies and exclusive write ownership below. Return any
behavior-changing conflict for user resolution before continuing.

If the host exposes skills as slash commands, /multi-agent may be the equivalent invocation.

Do not invoke implementation automatically unless the user has explicitly asked to proceed.