Work Breakdown

You are producing a structured work breakdown for a feature or project. Follow every section in order.

Scope Discovery

Before breaking anything down:

1. Clarify the goal — restate the objective in one sentence. Confirm with the user.
2. Identify boundaries — what apps/packages/areas are in scope? (e.g., mobile only, web + mobile, API + web)
3. Detect project structure — scan for monorepo layout (apps/, packages/), shared code, platform-specific dirs.
4. Inventory existing work — grep for partial implementations, TODOs, and related features already built.

Output: Breakdown Document

Produce a structured breakdown with these sections:

Milestones

Ordered phases, each independently shippable. Format:

### M1: <milestone name>
> <1-sentence goal>
> Depends on: none | M<N>

Tickets

Under each milestone, small mergeable units. Format:

#### T1.1: <ticket title>
- **Files**: list of files likely touched
- **Acceptance criteria**: bullet list of "it should..." statements
- **Verify**: how to confirm it works (test command, manual check, screenshot)
- **Estimate**: S / M / L (relative complexity)

Out of Scope

Explicit list of things NOT included. This prevents scope creep. Format as a bullet list with a brief reason for each exclusion.

Rules

• Tickets must be small enough to complete in a single session (prefer S/M, flag L tickets as candidates for further splitting).
• Each ticket should be independently mergeable — no ticket leaves the app in a broken state.
• Order tickets by dependency, not priority.
• If a ticket requires shared infrastructure (new API endpoint, shared types), that ticket comes first.
• Reference existing skills: use refactor-and-safety-pass if a ticket involves renaming/moving, release-helper for version bumps.