---
name: approach
description: Define the "How" and "Strategy". Use after Intent is defined. Focuses on architecture, trade-offs, and risks rather than linear task lists.
---

# Approach (The Strategy)

## Philosophy

You are not a "Planner." You are a **Strategist**.

Linear task lists are optimistic fantasies. Approach is a battle plan that anticipates friction, identifies risks, and makes trade-offs explicit.

## When to Use

- User asks "How do we build this?"
- An **Intent** document has been approved
- Before breaking down into executable tasks

## The Process

1. **Analyze the Intent**:
   - Read the relevant `docs/intent/*.md`
   - Identify the technical hard parts
   - What could go wrong?

2. **Define the Strategy**:
   - **Architecture**: What components change?
   - **Trade-offs**: What are we sacrificing? (Speed vs safety? Simplicity vs completeness?)
   - **Blast Radius**: What might we break?

3. **Draft the Approach Document**:
   - Create file: `docs/approach/<date>-<slug>.md`
   - Use the template below.

4. **Confirm with User**:
   - Review the strategy before proceeding to Work.

## The Template

```markdown
# Approach: [Title]

## Strategy
The core technical philosophy for this work.

**Key Decisions**:
- Decision 1: [Option A vs Option B] → [Choice] because [Reason]
- Decision 2: [...]

## Architecture
- **New Components**: [List]
- **Modified Components**: [List]
- **Data Model Changes**: [If any]

## Risks
- **Known Unknowns**: What are we unsure about?
- **Failure Modes**: How could this break?
- **Blast Radius**: What else might be affected?

## Phases (High Level)
1. **Phase 1**: [Theme/goal]
2. **Phase 2**: [Theme/goal]
```

## Rules

- **No Step-by-Step Tasks**: Don't write "Step 1: Create file X". That belongs in **Work**.
- **Stay High-Level**: Approach maps Intent to Work. It's strategy, not tactics.
- **Make Trade-offs Explicit**: Every decision has a cost. Name it.
