# MISSION.md Format

Lives at workspace root. Captures *why* the user learns this topic. Every teaching decision traces back here.

## Template

```md
# Mission: {Topic}

## Why
{1-3 sentences. The concrete real-world goal. What changes in their life/work when they have this skill? No abstract "to understand X" — push for the outcome.}

## Success looks like
- {Specific, observable thing the user will be able to do}
- {Another specific thing}

## Constraints
- {Time, budget, prior commitments, learning preferences — anything that bounds the approach}

## Out of scope
- {Adjacent topics the user does NOT want now — protects the zone of proximal development}
```

## Rules

- One mission per workspace. Two unrelated topics = two workspaces.
- Concrete over abstract. "Ship a Rust CLI to my team" beats "learn Rust".
- Push back on vagueness. Can't say why? Interview first. Bad mission is worse than none.
- Revise when reality shifts. Update in place — no stale mission steering sessions.
- Keep it short. Past one screen = it stopped being a compass.
