work-plan

name	work-plan
description	Break down complex tasks into actionable steps — define scope, identify dependencies, estimate effort, sequence work, and identify risks. Trigger on /work-plan, or when starting a complex task, planning a sprint, or breaking down ambiguous requirements.
user-invocable	true
allowed-tools	Read, Grep, Glob, Bash, Edit

Work Plan

Turn ambiguous requirements into actionable steps. Plan before coding, but don't overplan.

Workflow

1. Define scope

• What is the goal? State in one sentence.
• What is NOT in scope? Explicitly.
• What "done" looks like — acceptance criteria.
• What existing code/patterns can be reused?

2. Break down tasks

Split the work into the smallest meaningful steps. Each task should:

• Be independently completable and verifiable.
• Have a clear "done" condition.
• Take no more than a few hours (if possible).
• Not depend on unfinished tasks ahead of it.

Format:

[ ] Task 1: <what, why, file paths involved>
[ ] Task 2: ...
[ ] Task 3: ...

3. Identify dependencies

• Blocking: what must finish before this can start?
• Blocked: what depends on this?
• Shared: any files/resources multiple tasks touch? (risk of conflicts)
• External: any API, library, or team dependency?

4. Risk assessment

Risk	Likelihood	Impact	Mitigation
...	H/M/L	H/M/L	...

5. Sequence

Order tasks considering:

1. Dependencies (must-do-first)
2. Risk (do risky things early, before too much invested)
3. Value (deliver value incrementally)
4. Learning (do unknowns early to reduce uncertainty)

6. Estimate

Use t-shirt sizing (S/M/L/XL) or time ranges, not exact hours. Note assumptions behind each estimate.

Output

## Plan: <title>

### Goal
...

### Tasks
- [ ] Task 1 (S, ~2h) — ...
- [ ] Task 2 (M, ~4h) — ...
- [ ] Task 3 (L, ~1d) — ...

### Dependencies
- ...

### Risks
- ...

### Sequence
1. Task 3 (riskiest first)
2. Task 1 (foundation)
3. Task 2 (dependent on 1)

Rules

• Do not overplan — if the task is simple, a 3-line list is enough.
• Distinguish "known" from "assumed" — label assumptions explicitly.
• If requirements are too vague, flag it before planning.
• After planning, ask: "is this plan too big for one session?"
• Update the plan as you work — it's a living document.

Experience Log

This skill learns from experience. Mechanism:

• Read .claude/experience/work-plan.md at skill start to benefit from past lessons.
• Write to .claude/experience/work-plan.md after use if you learned something new.
• Format: YYYY-MM-DD: <lesson> — one line per entry.
• Evolve: If the same issue repeats 3+ times, update this SKILL.md itself.