---
name: plan-phase
description: Use when acting as Explorer or Creator in the Plan phase. Defines output formats for research and proposals.
---

# Plan Phase

Explorer researches, then Creator designs. Sequential — Creator needs Explorer's findings.

## Explorer Output Format

```markdown
## Research: <task>

### Affected Code
- `path/file.ext` — description (L<start>-<end>)

### Dependencies
- What depends on what, what breaks if changed

### Patterns
- How the codebase solves similar problems

### Risks
- What could go wrong

### Recommendation
<one paragraph: approach + rationale>
```

## Creator Output Format

```markdown
## Proposal: <task>
**Confidence:** <0.0 to 1.0>

### Architecture Decision
<What and WHY>

### Changes
1. **`path/file.ext`** — What changes and why
2. **`path/test.ext`** — What tests to add

### Test Strategy
- <specific test cases>

### Risks
- <what could go wrong + mitigations>

### Not Doing
- <adjacent concerns deliberately excluded>
```

## Creator with Prior Feedback (Cycle 2+)

When the Creator receives structured feedback from a prior cycle, the proposal must include an additional section addressing each unresolved issue:

```markdown
## Proposal: <task> (Revision — Cycle N)
**Confidence:** <0.0 to 1.0>

### Prior Feedback Response
| Issue | Source | Action | Rationale |
|-------|--------|--------|-----------|
| SQL injection in user input | Guardian | **Fixed** — added parameterized queries | Direct security fix |
| Assumes single-tenant | Skeptic | **Deferred** — multi-tenant out of scope | Not in task requirements |
| Test names unclear | Sage | **Accepted** — routed to Maker | Implementation concern |

### Architecture Decision
<revised design addressing feedback>

### Changes
<updated file list>

### Test Strategy
<updated test cases>

### Risks
<updated risks — include any new risks from the revision>

### Not Doing
<updated scope boundaries>
```

**Rules for addressing feedback:**
- **Fixed:** Changed the design to resolve the issue. Explain how.
- **Deferred:** Not addressing now, with explicit reason. Must not be a CRITICAL finding.
- **Accepted:** Acknowledged and routed to Maker for implementation-level fix.
- **Disputed:** Disagrees with the finding. Must provide evidence or reasoning.

CRITICAL findings cannot be deferred or disputed — they must be fixed or the proposal will be rejected again.