| name | task-plan |
| description | Decompose input into a structured task backlog for automated agent loops. Use when asked to "create a task plan", "break this into tasks", "decompose this PRD", "turn this into a backlog", or "plan tasks from" any input source (PRD, Figma feedback, GitHub issues, user requirements). Also use when the user provides a PRD, design doc, or requirements and wants executable tasks, even if they don't mention "task plan" explicitly.
|
Task Plan
Turn any input source into a structured backlog that an agent can execute
one task at a time in an automated loop. Each task is self-contained,
verifiable, and completable in a single iteration.
When to use
Invoke when the user has an input source (PRD, design feedback, issue list,
requirements doc, or verbal description) and wants it decomposed into
executable tasks. The output is a backlog.md file — a flat task list
with dependency graph and priority ordering.
Process
1. Understand the input
Accept input as a file path, URL, pasted text, or verbal description.
If none provided, interview the user:
- What are you trying to build or change?
- What does the end state look like?
- What exists today?
- What constraints matter (timeline, tech stack, compatibility)?
Interview deeply — understand intent, not just surface requirements.
The quality of the backlog depends on understanding the why.
2. Explore the codebase
Before decomposing, explore the codebase to understand:
- Existing patterns and conventions
- Architecture and integration layers
- What already exists that tasks can build on
- Testing patterns and verification infrastructure
Tasks that ignore existing code lead to rework. An agent executing a
task should extend the codebase, not fight it.
3. Surface durable decisions
Identify decisions that span multiple tasks and are unlikely to change:
- Route structures / URL patterns
- Schema shapes and data models
- Key architectural boundaries
- Third-party service interfaces
- Shared component patterns
These go in a ## Decisions section at the top of the backlog so every
task can reference them without repeating context.
4. Ask about reference material
Ask the user: "Are there docs, skills, or reference material that will
help an agent execute these tasks?"
Examples:
- A Figma workflow doc for design tasks
- API documentation for integration tasks
- A testing guide for the project
- An existing skill relevant to the tech stack
These go in the backlog's reference table so the executing agent knows
where to look.
5. Decompose into vertical slices
Break the input into tasks. Each task is a thin vertical slice through
all relevant layers (model, logic, API, UI, tests), not a horizontal
layer.
Apply these heuristics — read references/task-quality.md for details:
The one-iteration test: Can a fresh agent session complete this task
in one loop iteration (~30 min)? If not, split it.
The one-commit test: Does this task produce exactly one coherent
commit? If it would need multiple commits, split. If it's too small to
commit alone, merge with a sibling.
The cold-start test: Does the task contain enough context (file paths,
current state, what to change, how to verify) that an agent with no
session memory can execute it? If not, add more detail.
The revert test: Could this commit be reverted cleanly, removing
exactly one meaningful thing? If reverting would orphan code or break
something unrelated, the task isn't self-contained.
6. Structure each task
Each task needs all of these fields:
- ID — short prefix + number (e.g. AU-1, DB-3). Prefix groups
related tasks (CC = cross-cutting, AU = auth, UI = interface, etc.)
- Title — what changes, not how
- Size — XS (< 10 min), S (10-20 min), M (20-40 min), L (40+ min).
If L, strongly consider splitting
- Deps — task IDs this depends on, or "none"
- Problem — what's wrong or missing (the why)
- What to do — concrete steps with file paths and current state
- Acceptance criteria — observable outcomes, not implementation details
- Verification — exact commands to run and what to check. Can
reference global verification rules or be task-specific
- Files — paths that will be touched
Read references/backlog-format.md for the full template.
7. Add dependency graph and priority order
Draw the dependency graph as a text diagram showing which tasks unblock
others. Group tasks into phases where tasks within a phase can be
executed in parallel (no mutual dependencies).
Priority order should generally be:
- Cross-cutting / foundation tasks (unblock many others)
- Quick wins (XS tasks, batch together)
- Feature phases (grouped by domain area)
- Polish and documentation
8. Quiz the user
Present the proposed breakdown as a summary. Ask:
- Does the granularity feel right? (too coarse / too fine)
- Should any tasks be merged or split?
- Are the dependencies correct?
- Is the priority order right?
- Anything missing?
Iterate until approved, then write the file.
9. Write the backlog
Write to the path specified by the user (default: TASKS/<name>/backlog.md).
Create the directory if needed.
If the user plans to use /task-loop next, mention that the backlog is
ready for loop scaffolding.
