← Back to Bevy · project planning pack
See how it helps
Implementation task breakdown
Breaks a game feature into ordered tasks that each deliver a complete, reviewable player outcome. Makes dependencies, data contracts and acceptance checks explicit before parallel work begins.
task-breakdown
Agents using this skill
When is it useful?
Use it when a feature is too large for one change or several contributors need clear contracts and dependencies.
What does it help you do?
- Maps dependencies and existing patterns before changing code.
- Slices work into complete user paths with explicit contracts.
- Defines testable acceptance criteria, risks and integration order.
Try asking this
Split a cooperative quest system into deliverable steps: shared quest state, progress updates, completion and one-time rewards. For each step, name the owning module, prerequisite and visible acceptance check. Include reconnect behavior early enough that saving and UI work do not build on incompatible assumptions.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Task Breakdown
Split the work into small tasks that can each be built, tested and checked in one focused session, in an order that keeps the system working.
Plan before code
- Planning is read-only: read the spec and the code involved, note the existing patterns, map dependencies, list risks and unknowns. Write no code while planning.
- Build the dependency graph and plan bottom-up: schema, then models and types, then endpoints and validation, then the client, then the UI.
Slice vertically
- Each task delivers one working path through the stack that can be tested: "user can create a task (schema + API + UI)", not "build all endpoints".
- When front end and back end proceed in parallel, define the contract first (types, endpoints, error shapes) as its own task; both sides build against it, then integrate.
- Put the riskiest or most uncertain slice first, to fail fast.
Size
| Size | Files | Scope |
|---|---|---|
| XS | 1 | One function or config change |
| S | 1–2 | One component or endpoint |
| M | 3–5 | One feature slice |
| L | 5–8 | Several components: split it |
| XL | 8+ | Too large: split it |
| Aim for S and M. Split a task when it needs more than one session, when its acceptance criteria take more than 3 bullets, when it touches two independent subsystems, or when its title needs an "and". |
Write each task as a brief
The brief is the contract for whoever builds it, possibly another agent days later:
- Goal: one line on what must happen.
- Current behavior and desired behavior, including edge cases and error conditions.
- Key interfaces: the types, function signatures, endpoints and config shapes that change. Describe behavior and contracts, not file paths or line numbers; those go stale.
- Acceptance criteria: specific, each testable on its own ("returns 404 for a deleted id", not "works correctly").
- Verification: the tests to run, the build, and the manual check.
- Dependencies: the tasks that must land first, or none.
- Out of scope: what must not change, and nearby features that look related but are separate. Say what the system must do, not how to code it.
Order and checkpoints
- Satisfy dependencies first; every task leaves the system building and its tests green.
- Add a checkpoint after every 2–3 tasks: all tests pass, the build is clean, the core flow works end to end.
- Parallel work: independent slices, tests for finished features and documentation can run side by side. Migrations, shared state and dependency chains run in sequence. Features that share a contract wait for the contract.
- Give tasks that run at the same time separate files; two builders never edit the same files.
Record the plan
- Record tasks where the project tracks work: the work items or issue tracker in use, with their dependencies linked, or the plan itself. Never overwrite or close another plan's open tasks to make room; ask.
- The plan states: an overview, key decisions with reasons, the tasks by phase with checkpoints, risks with impact and mitigation, and open questions for a human.
Before you finish
- Every task has a goal, acceptance criteria, verification and dependencies.
- Tasks are vertical slices of size S or M; none touches more than about 5 files.
- Order respects dependencies; risky work comes early; checkpoints exist.
- Parallel tasks do not share files; shared contracts come first.
- Out of scope and open questions are written down.
Included files 2
LICENSE.txtSKILL.md