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):

```markdown
# Plan: <task name>

## task_plan Positioning
Corresponds to Phase: <Phase number and name from task_plan.md, or "N/A" if no task_plan>
Position in overall plan: <dependencies, what completing this unlocks>

## Motivation
<1-3 sentences: WHY + consequence of not doing it>

## Core Assumptions
| Assumption | What if wrong | Verification method |
|-----------|---------------|-------------------|

## Design Decisions
| Decision point | Choice | Alternative | Reason for choice |
|---------------|--------|-------------|-------------------|

## Acceptance Criteria
| Metric | Type | Measurement (command) | Expected value/range | Tolerance |
|--------|------|----------------------|---------------------|-----------|

## Implementation Plan

### Phase 1: <phase name>
- ...

### Phase 2: ...

## Verification
L1: <specific items>
L2: <specific items>
L3: <specific items>
L4: <specific items>

## Files Involved
| # | File | Change type |
|---|------|------------|
```

**Write**: Write the above content to the plan file (path specified in Plan Mode system message).

**Output**:

```
Plan complete:
- Motivation: <one sentence>
- Assumptions: <N> (<M> have verification methods)
- Solution: <chosen solution> (compared <K> alternatives)
- Acceptance criteria: <N> (quantitative <X> / behavioral <Y>)
- Phases: <N>
→ ExitPlanMode
```

Then immediately call `ExitPlanMode`.

## Key Constraints

- **Each Phase has a depth gate**: Can't pass = don't proceed to next Phase, return to current one
- **Don't skip Phases**: Even if the user gave very detailed requirements, still go through each (Phase 1-2 may be quick, but can't skip)
- **Questioning is not adversarial**: The goal is to help the user think clearly, not to grill them. But "I agree with everything you said" is not good discussion
- **Use AskUserQuestion**: Don't self-answer in your output — actually ask the user
- **Explore code**: For assumptions/solutions involving existing code in Phase 2-3, use Glob/Grep/Read to actually confirm

## Forbidden

- Using assumptions instead of questions ("I assume you want X" → should ask "X or Y?")
- Outputting a complete solution in the first round
- Moving to Phase 5 after only one round of questions
- Phase 4 writing "no quantitative metrics" without behavioral metrics as substitute (at minimum, have behavioral metrics)