| 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:
- Dependencies (must-do-first)
- Risk (do risky things early, before too much invested)
- Value (deliver value incrementally)
- 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.
