Deep Deliberation

Leading words: option tree, evidence tournament, reversibility, adversarial review, premortem, uncertainty, checkpoint, ground truth, circuit, autopilot, plain question.

Deep Deliberation frames a consequential decision, compares viable alternatives, tests them against evidence, and adjudicates unresolved risks. The pipeline produces a decision record. Implementation starts only after Checkpoint 3 approval, or immediately under --autopilot.

User Input

$ARGUMENTS

Parse a pace flag from arguments before treating the rest as the decision: --circuit, --autopilot, --auto (alias of --autopilot). Strip the flag from the decision text. If both circuit and autopilot appear, autopilot wins.

Pace modes (optional)

Default is interactive: stop and wait at every checkpoint.

The user must opt in this invocation — a flag above, or an explicit phrase (circuit, autopilot, take recommended, circuit the rest, autopilot the rest). Do not infer from urgency. Mid-run, the same phrases switch mode from the current checkpoint. stop circuit / stop autopilot drops back to interactive.

Mode	Intermediate checkpoints (1–2)	Final checkpoint (3)
interactive	Stop and wait	Stop and wait. Do not implement until a separate ask
--circuit	Auto-accept the recommended choice; log and continue	Stop. Ask whether to go ahead with the final recommendation
--autopilot	Auto-accept; log and continue	Auto-accept. Treat the recommendation as the way to proceed

Skip the wait, not the work. Stages, evidence tournament, and adjudication still run. Emit a compact PACE_LOG of every auto-accepted choice.

Cannot proceed: if there is no unique recommendation (tie, both options invalidated, return to Stage 1 required, degraded delegates below minimum), stop and ask even on autopilot.

Proceed (autopilot, or circuit after the user says go ahead): accept the recommendation as the decision and start implementing it. That is the way forward. The decision record is still emitted first.

This skill shares --circuit / --autopilot grammar with dissect.

Interactive final footer. On Checkpoint 3 only, when this run is interactive, append the block below verbatim as the last thing in the message (after the Checkpoint 3 ask). Omit it under --circuit / --autopilot. Do not paraphrase. Do not place it earlier.

⚡ **Skip the waits next time**

This run was **interactive** — a stop at every checkpoint. Same skill, two other paces:

- `--circuit` — take the recommended choices through the middle checkpoints, then stop at the final recommendation and ask before proceeding.
- `--autopilot` — take every recommended choice, including the last, and proceed without waiting.

`/deep-deliberation --circuit <decision>` · `/deep-deliberation --autopilot <decision>`

User questions (plain question)

The report may be technical. The ask must not be.

Same turn as the checkpoint message: host structured question tool (Cursor AskQuestion, Claude Code AskUserQuestion, OpenCode equivalent). No tool → numbered list. Do not replace the template. Then stop.

Prompt: one sentence, product language. No DELIBERATION_STATE fields. Labels ≤40 chars. First ends (Recommended). Last is always Say this in plain English (meta: do not advance; rephrase + one example of what each real option means here; re-ask). Second pick: a simpler analogy. Free-text overrides. Per-option descriptions: one plain sentence if the host supports them. Any ask to the human (including cannot-proceed and delegate failure) follows this contract.

Operating contract

• Do not edit files, implement code, or create formal plan documents while the pipeline is active. Proceeding (above) happens after Checkpoint 3 is accepted, not during Stages 1–3.
• Ground claims in repository evidence and current external sources when the decision depends on them.
• Keep at least two viable approaches through Stage 2 to resist early anchoring.
• Preserve material disagreements; never silently average them away.
• Treat isolated delegates as separate contexts, not independent authorities.
• Never invent missing delegate findings or unsupported evidence.
• Interactive: stop after every checkpoint; continue only after the user explicitly responds. --circuit / --autopilot: skip waits as in Pace modes.
• The user may revise, restart, or end the pipeline at any checkpoint.
• A meta question (including Say this in plain English) does not advance the state; rephrase, re-ask, remain at the current checkpoint.

Runtime state

Start every pipeline response with this block and update it mechanically:

DELIBERATION_STATE
stage: 1 | 2 | 3
checkpoint: none | 1 | 2 | 3
mode: interactive | circuit | autopilot
shortlist: unset | A,B
delegate_results: 0/N
next_action: one action only

If the state is missing after a context change, reconstruct it from the latest completed template and ask a plain question before advancing.

Pipeline

1. Stage 1 — Frame and shortlist: define the decision, generate 3–5 approaches, and shortlist the strongest two.
2. Checkpoint 1: user approves the framing and shortlist (auto-accepted under --circuit / --autopilot).
3. Stage 2 — Evidence tournament: 3–5 focused reviewers compare both shortlisted approaches using a normalized evidence contract.
4. Checkpoint 2: user reviews findings and unresolved disputes (auto-accepted under --circuit / --autopilot).
5. Stage 3 — Adjudication: targeted evidence review and premortem produce the final recommendation.
6. Checkpoint 3: interactive waits; --circuit asks whether to go ahead; --autopilot proceeds.

No implementation follows automatically unless --autopilot is on, or the user says go ahead at the circuit ask.

Stage 1 — Frame and shortlist

Stage 1 is performed by the orchestrator without delegates.

Entry gate

If the decision is materially ambiguous, ask a plain question before starting Stage 1. If the task primarily audits something already built or written, recommend dissect instead.

If two cheap throwaway sketches would settle the fork, offer that prototype off-ramp before Stage 1: scratch dir, no pipeline, observe the behavior, then resume here with evidence. Skip with skip: shape already concrete or skip: pace mode under --circuit / --autopilot. Interactive off-ramp ask:

prompt: Two cheap sketches might settle this faster than a full comparison. Try that first?
options:
- Yes, sketch both first (Recommended)
- No, run the full comparison
- Say this in plain English

When a candidate crosses a function boundary, sketch types and signatures first (not implemented). Screen with references/design-red-flags.md. Scrap the sketch when the same workaround repeats.

Procedure

1. Inspect relevant code, schemas, documentation, constraints, and prior decisions.
2. State the decision, desired outcome, constraints, non-goals, assumptions, evidence gaps, decision horizon, reversibility, and cost of delay.
3. Declare evaluation criteria before evaluating options. Use must, important, and preference; use numeric weights only when defensible.
4. Generate 3–5 meaningfully different approaches. For each, state its mechanism, expected benefit, main downside, critical assumptions, supporting evidence, reversibility, rough effort, and failure condition.
5. Remove clearly dominated options with an explicit reason.
6. Shortlist the strongest option and strongest challenger. Relabel them Option A and Option B for the remaining stages. Do not make the final recommendation yet.

Read references/output_templates.md, emit the complete Stage 1 template, set checkpoint: 1. Interactive: stop. --circuit / --autopilot: log the shortlist as auto-accepted and continue to Stage 2.

Checkpoint 1 choices (interactive) — structured question per User questions:

prompt: I'll compare “[A short name]” vs “[B short name]”. Is that the right choice to decide?
options:
- Yes, compare those two (Recommended)
- Swap or rewrite an option
- Change what we're optimizing for
- This is obvious now — stop
- Say this in plain English

Stage 2 — Evidence tournament

Stage 2 compares both shortlisted approaches. It does not defend a winner chosen in Stage 1.

Reviewer missions

Use these four default missions:

1. Feasibility and integration
2. Failure, security, and edge cases
3. Operations, migration, and cost
4. Challenger advocate

Add one domain specialist only when the decision clearly requires expertise not covered above. Omit a default mission only when it is demonstrably irrelevant; never run fewer than three reviews without user approval.

Procedure

1. Identify specific repository files and authoritative external sources needed to evaluate the decision.
2. Read references/subagent_prompt.md.
3. Launch one isolated, read-only delegate per mission using the host's supported mechanism. Use the host's default model unless the user requested another.
4. Launch delegates together when parallel dispatch is available. Launch and synthesis are separate assistant steps.
5. After results return, normalize and cluster them into evidence-backed blockers, fixable risks, minor concerns, unverified claims, disagreements, and evidence favoring the challenger.
6. If evidence invalidates both options, return to Stage 1 after user approval.

Each delegate returns no more than three findings. Every finding must contain:

claim:
evidence:
source:
impact: blocker | fixable | minor | unverified
confidence: high | medium | low
affected_option: A | B | both
falsifier:

A blocker without evidence is unverified, not fatal.

Read references/output_templates.md, emit the complete Stage 2 template, set checkpoint: 2. Interactive: stop. --circuit / --autopilot: log the synthesis as auto-accepted and continue to Stage 3, unless Return to Stage 1 required: yes (then stop even on autopilot).

Checkpoint 2 choices (interactive) — structured question per User questions:

prompt: Both options still stand. Ready for me to pick a winner?
options:
- Yes, pick a winner (Recommended)
- Change an option and re-check
- Start over with a different fork
- Stop here
- Say this in plain English

Stage 3 — Adjudication

Stage 3 resolves uncertainty instead of repeating Stage 2 with new personas.

Run these two read-only review missions:

1. Evidence adjudicator: verify disputed and high-impact claims; distinguish corroboration from repeated assertion.
2. Premortem challenger: assume the leading option failed six months after launch, identify the most plausible causes, and present the strongest remaining case for the runner-up.

Add a third domain adjudicator only when a Stage 2 dispute requires specialized resolution.

The orchestrator then produces:

• Recommendation and rationale
• Comparison against the declared criteria
• Evidence that determined the decision
• Verified and unverified assumptions
• Material disagreements
• Reversibility and rollback cost
• Premortem risks and mitigations
• Conditions that would change the recommendation
• Ranked alternatives
• Cheapest experiment or spike that could reduce remaining uncertainty
• One next action appropriate to the session's current capabilities

Read references/output_templates.md, emit the complete Final template, set checkpoint: 3.

• Interactive: stop. Do not implement. End the message with the interactive final footer (Pace modes) — last block, verbatim.
• --circuit: stop. Structured question per User questions. If they say no, stay at this checkpoint.
• --autopilot, or circuit after they say go ahead: proceed — accept the recommendation and start implementing it.

Checkpoint 3 choices (interactive / circuit) — structured question per User questions:

prompt: I recommend “[chosen]”: [one-line why]. Make that the decision?
options:
- Yes, go with that (Recommended)
- Pick the other option
- Change something first
- Plan or build it next
- Say this in plain English

Delegate failure protocol

1. Retry one transient delegate failure.
2. Report unavailable missions explicitly.
3. If fewer than three Stage 2 reviews or fewer than two Stage 3 reviews return, ask whether to retry or continue in labelled degraded mode.
4. If delegation is unavailable, state DELEGATED_REVIEW_UNAVAILABLE and ask before substituting isolated orchestrator passes.
5. Never synthesize findings that were not returned.

Completion check

Before declaring the pipeline complete, verify:

• At least two viable approaches received adversarial comparison.
• High-impact claims carry evidence or are labelled unverified.
• Reversibility and residual uncertainty are explicit.
• Material disagreements remain visible.
• The recommendation states what evidence would overturn it.
• No implementation occurred before Checkpoint 3 was accepted (interactive / circuit wait) or auto-accepted (--autopilot).
• Interactive Checkpoint 3 ended with the pace-mode footer as the last block.

References

• references/subagent_prompt.md — portable delegate dispatch, reviewer prompt, evidence contract, and failure handling.
• references/output_templates.md — exact Stage 1, Stage 2, and Final response structures.