Planning And Task Breakdown
Convert an approved spec into small, ordered, testable tasks with dependencies so your agent (or you) can implement without scope drift.
Overview
Planning and Task Breakdown is an agent skill most often used in Build (also Validate) that breaks specs into ordered, verifiable tasks with a dependency graph before any implementation.
Install
npx skills add https://github.com/addyosmani/agent-skills --skill planning-and-task-breakdownWhat is this skill?
- Read-only plan mode: no code during planning—output is a plan document
- Dependency graph mapping so schema, API, and UI layers ship in safe order
- Tasks sized for a single focused implement-verify session
- Explicit acceptance criteria per task for reliable agent completion
- When NOT to use: single-file obvious changes or specs that already contain well-defined tasks
- Planning process includes Step 1 Enter Plan Mode and Step 2 Identify the Dependency Graph
Adoption & trust: 5.1k installs on skills.sh; 49.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a spec or clear requirements but no ordered, testable task list your agent can execute without tangled dependencies.
Who is it for?
Solo builders running Claude Code or similar agents on multi-file features where order and verification matter.
Skip if: Single-file changes with obvious scope or specs that already list well-defined tasks—the skill says to skip those cases.
When should I use this skill?
Use when you have a spec or clear requirements and need implementable tasks, scope feels too large, you need estimates, or parallel work is possible.
What do I get? / Deliverables
You get a plan document with a dependency graph and session-sized tasks with acceptance criteria, ready for focused implementation passes.
- Plan document with ordered tasks
- Dependency graph between components
- Per-task acceptance criteria
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Task breakdown is the bridge from requirements to implementation during build, even when the spec was written earlier in validate. PM subphase is the canonical shelf for decomposition, acceptance criteria, and implementation ordering.
Where it fits
Map database schema → API types → routes before the agent touches UI so migrations land first.
Break an MVP spec into estimable chunks to decide what ships in week one.
Turn release checklist items into ordered tasks with rollback-aware acceptance criteria.
Parallelize two agent sessions only after the skill exposes shared contract dependencies.
How it compares
Structured plan-mode decomposition instead of ad-hoc chat planning that mixes coding and ordering in one thread.
Common Questions / FAQ
Who is planning-and-task-breakdown for?
Indie developers and agent-first builders who have requirements written down and need implementable, ordered work units.
When should I use planning-and-task-breakdown?
In Validate when scoping feels vague; in Build PM when a spec exists but tasks are missing; before parallel agent sessions when dependencies must be explicit.
Is planning-and-task-breakdown safe to install?
It is planning guidance that reads your repo and spec; review the Security Audits panel on this Prism page and limit agent read access as you prefer.
SKILL.md
READMESKILL.md - Planning And Task Breakdown
# Planning and Task Breakdown ## Overview Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session. ## When to Use - You have a spec and need to break it into implementable units - A task feels too large or vague to start - Work needs to be parallelized across multiple agents or sessions - You need to communicate scope to a human - The implementation order isn't obvious **When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks. ## The Planning Process ### Step 1: Enter Plan Mode Before writing any code, operate in read-only mode: - Read the spec and relevant codebase sections - Identify existing patterns and conventions - Map dependencies between components - Note risks and unknowns **Do NOT write code during planning.** The output is a plan document, not implementation. ### Step 2: Identify the Dependency Graph Map what depends on what: ``` Database schema │ ├── API models/types │ │ │ ├── API endpoints │ │ │ │ │ └── Frontend API client │ │ │ │ │ └── UI components │ │ │ └── Validation logic │ └── Seed data / migrations ``` Implementation order follows the dependency graph bottom-up: build foundations first. ### Step 3: Slice Vertically Instead of building all the database, then all the API, then all the UI — build one complete feature path at a time: **Bad (horizontal slicing):** ``` Task 1: Build entire database schema Task 2: Build all API endpoints Task 3: Build all UI components Task 4: Connect everything ``` **Good (vertical slicing):** ``` Task 1: User can create an account (schema + API + UI for registration) Task 2: User can log in (auth schema + API + UI for login) Task 3: User can create a task (task schema + API + UI for creation) Task 4: User can view task list (query + API + UI for list view) ``` Each vertical slice delivers working, testable functionality. ### Step 4: Write Tasks Each task follows this structure: ```markdown ## Task [N]: [Short descriptive title] **Description:** One paragraph explaining what this task accomplishes. **Acceptance criteria:** - [ ] [Specific, testable condition] - [ ] [Specific, testable condition] **Verification:** - [ ] Tests pass: `npm test -- --grep "feature-name"` - [ ] Build succeeds: `npm run build` - [ ] Manual check: [description of what to verify] **Dependencies:** [Task numbers this depends on, or "None"] **Files likely touched:** - `src/path/to/file.ts` - `tests/path/to/test.ts` **Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files] ``` ### Step 5: Order and Checkpoint Arrange tasks so that: 1. Dependencies are satisfied (build foundation first) 2. Each task leaves the system in a working state 3. Verification checkpoints occur after every 2-3 tasks 4. High-risk tasks are early (fail fast) Add explicit checkpoints: ```markdown ## Checkpoint: After Tasks 1-3 - [ ] All tests pass - [ ] Application builds without errors - [ ] Core user flow works end-to-end - [ ] Review with human before proceeding ``` ## Task Sizing Guidelines | Size | Files | Scope | Example | |------|-------|-------|---------| | **XS** | 1 | Single function or config change | Add a validation rule | | **S** | 1-2 | One component or endpoint | Add a new API endpoint | | **M** | 3-5 | One feature slice | User registration flow | | **L** |