/deep-plan

name: deep-plan
description: |
  Structured deep discussion for Plan Mode. Runs inside EnterPlanMode to ensure thorough
  questioning before writing a plan. Covers motivation, assumptions, design, acceptance criteria.
  Call this immediately after entering Plan Mode for any non-trivial task.

autoworker:deep-plan — Structured Deep Discussion (Inside Plan Mode)

Invoke immediately after entering Plan Mode. Ensures discussion depth through 5 structured phases, producing a structured plan file for autoworker:subtask-init to extract from.

**Core idea**: Plan depth determines the quality ceiling of the execution chain. autoworker:subtask-init **extracts** from the plan file, autoworker:subtask-plan **derives** the verification plan from it. If the discussion is shallow, the entire chain — no matter how well-structured — is verifying an insufficiently thought-through solution.

Execution Flow

Phase 1: Motivation Exploration

**Goal**: Understand what problem the user truly needs to solve, rather than rushing to think about how.

**Pre-action**: Check if the project has a `task_plan.md`. If so, read the overall goals and phase list; subsequent questioning should address the relationship to the overall plan.

**Questioning approach** (use AskUserQuestion, 2-3 questions per round):

1. **Why do this?** Do not accept tautological answers like "because we need X". Probe to root causes at the business/experience/efficiency level. 2. **Relationship to overall goal?** (when task_plan exists) Which phase does this correspond to? Is it planned or ad-hoc? If ad-hoc, why is it higher priority than planned phases? 3. **What if we don't do it?** What's the worst consequence? Can we tolerate it? The lighter the consequence, the simpler the solution should be. 4. **Is this really needed?** Is there a simpler way (don't do it, do it manually, approach from a different angle)?

**Anti-patterns**:

• User says "add caching" → immediately designing cache solution → should first ask "why is it slow?"
• User says "refactor to X" → immediately designing X architecture → should first ask "what problem does refactoring solve?"
• User gives detailed solution → skip motivation and discuss implementation → the solution might be the user's guess, not optimal

**Depth gate**: Motivation expressible in 1-3 clear sentences (WHY + consequence of not doing it). Can't write it = don't understand it = keep asking.

---

Phase 2: Assumption Challenge

**Goal**: Make implicit assumptions explicit and challenge each one.

**Steps**:

1. **List assumptions**: Extract all implicit premises from Phase 1 discussion

• Technical assumptions (API available, data format stable, dependencies reliable...)
• Requirement assumptions (user actually needs this, frequency is high enough, priority is correct...)
• Environment assumptions (has GPU, network works, permissions sufficient...)

2. **Challenge each one** (AskUserQuestion):

• "You assumed X — what happens if X doesn't hold?"
• "Can this assumption be verified? With what command?"
• "Is there anything you consider 'obviously true' but haven't actually confirmed?"

3. **Explore code** (Glob/Grep/Read):

• When assumptions involve existing code, actually read the code to confirm — don't rely on memory

**Depth gate**: Each assumption either has a verification method (one-line command) or is flagged as risk ("cannot pre-verify, monitor during execution").

---

Phase 3: Solution Derivation

**Goal**: Derive solution from motivation, not apply from experience.

**Steps**:

1. **Start from motivation**: What's the minimum-change solution to the problem confirmed in Phase 1? 2. **At least 1 alternative**: What are the trade-offs of different approaches? 3. **Use AskUserQuestion for user to choose**: Present solution comparison, let user decide based on trade-offs

**Solution review — four questions** (any unsatisfactory → redesign):

0. **Is the direction right?** Derived from problem essence, or pattern-matched from similar scenarios? 1. **Is the abstraction level right?** Does the caller naturally possess this capability, letting us do only structured operations? 2. **10x robustness**: Still robust if input diversity increases 10x? Can enumeration scale? 3. **Does a simpler solution exist?** Same effect, less code/assumptions?

**Depth gate**: User explicitly chose a solution + can articulate the reason.

---

Phase 4: Acceptance Criteria

**Goal**: Define how to judge "done", giving the execution phase clear expectations.

**Steps** (AskUserQuestion):

1. **Categorized discussion**:

• **Quantitative** (data precision, performance, coverage): specific values + tolerance
• **Behavioral** (workflow changes, instruction files): "Scenario X → expected behavior Y"

2. **Every metric must have a measurement method**:

• Quantitative: what command to test? Expected output?
• Behavioral: how to simulate the scenario? How to observe behavior?

3. **Confirm completeness with user**:

• "Besides these metrics, what other situation counts as 'not done'?"
• "If all these metrics pass, will you accept it?"

**Depth gate**: Every metric can directly become an L4 test case (has input, has operation steps, has expected output).

**Standard for "discussed thoroughly"**: Goals, motivation, core assumptions, acceptance criteria all clear — during execution, when actual results deviate, you can logically analyze the cause rather than guess blindly.

---

Phase 5: Plan Output

**Goal**: Consolidate Phase 1-4 discussion output into the plan file.

**95% confidence self-check**: If you write the plan now and the user accepts it, would they overturn it due to misunderstanding? No = ready to output. Yes = return to the relevant Phase and continue discussing.

**Plan file format** (fixed structure, autoworker:subtask-init extracts by section):

# Plan: <task name>

## task_plan Positioning
Corresponds to Phase: <Phase number and name from