From team-core
Break a spec, plan, or clear requirement into ordered tasks that are small enough to complete in one focused session, organized as vertical slices so each task produces a working outcome. Use after a spec or plan is approved — not to explore open questions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/team-core:task-breakdownThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A useful task breakdown is the difference between work that ships reliably and work that sprawls into a tangled mess. This skill produces tasks that an individual can pick up, finish, and verify in one session — organized so the project reaches a working state at every checkpoint, not only at the end.
A useful task breakdown is the difference between work that ships reliably and work that sprawls into a tangled mess. This skill produces tasks that an individual can pick up, finish, and verify in one session — organized so the project reaches a working state at every checkpoint, not only at the end.
/role-pgm:project-planner./role-pgm:sprint-planner./role-pm:spec-draft or /role-ceo:office-hours.Read the spec / plan / requirement end to end. Identify:
If any of these are unclear, stop and ask one specific question at a time. Don't guess structure on a fuzzy spec.
Identify the minimal set of components each feature path depends on. Sketch the graph mentally (or write it out briefly in the output).
Mark each node as:
Foundations come first. Feature slices are ordered by dependency and by learning value — start with the slice that most quickly reveals whether the approach works.
Each task has:
### Task N: <verb + object>
**What:** <1 sentence>
**Why:** <1 sentence — how this moves the outcome forward>
**Acceptance criteria:**
- <specific, observable>
- <specific, observable>
**Files touched (estimate):** <count + most-likely paths>
**Depends on:** <task numbers, or "none">
**Verification:** <how you'll know this task is done — test passes, manual check, screenshot, etc.>
Rules:
invalid_input when payload fails validation, and log entry includes request ID" is.Order the tasks so that:
Checkpoint example:
### Checkpoint after Task 4
- All existing tests pass
- New endpoint `/v1/widgets` returns 200 on happy path
- Manual verification: create a widget via curl, see it in the DB
# Task breakdown: <input title>
**Vertical slices in order:**
1. <slice name> — tasks 1-4 — checkpoint after 4
2. <slice name> — tasks 5-7 — checkpoint after 7
3. <slice name> — tasks 8-10 — final checkpoint
---
## Foundations
### Task 1: <...>
<full task spec>
### Task 2: <...>
...
## Slice 1: <slice name>
### Task 3: <...>
...
### Checkpoint after Task N
- <verification step>
## Slice 2: <slice name>
...
## Polish
### Task K: <...>
...
---
## Total estimate
- <N tasks>, roughly <hours> of focused work
- Assumes <any assumption made, e.g. "existing auth middleware reused without modification">
- Risks / unknowns: <things that could invalidate the breakdown>
Methodology inspired by the Addy Osmani "planning-and-task-breakdown" skill.
npx claudepluginhub sitloboi2012/team-marketplace --plugin team-coreCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.