get-tasks

# Get Tasks ## Overview `get-tasks` converts an approved PRD into an executable set of tasks. Each task is written to its own file, sized to fit a single focused session, ordered by dependency, and shipped with acceptance criteria, validation steps, a blocking list, and a rollback procedure. The reason this exists as its own skill: **a PRD is not a plan**. A PRD states what the system does and why. It says nothing about the order of work, what can be built in parallel, where the risky parts are, or how to prove a slice is done. Turning a PRD straight into code produces either a heroic single-pass change or an arbitrary order that breaks halfway. `get-tasks` supplies the missing layer. It reads the PRD, maps the real dependency structure, cuts the work into vertical slices, and writes each slice as a standalone artifact that an agent (or a human) can pick up without re-reading the whole PRD. This skill draws from three sources: 1. **Dependency-first decomposition and vertical slicing** — build a dependency graph, slice vertically rather than horizontally, size each task, and place checkpoints. This is what makes the order correct. 2. **Validation-driven execution** — every task declares how it will be verified across multiple validation types, not just "tests pass", and carries a replan procedure for when a step fails. 3. **Blocking edges and tracer bullets** — each task states explicitly what blocks it, so any task whose blockers are done can start immediately. The output is a directory of task files: `tasks/<name>/task-01.md`, `task-02.md`, and so on, numbered in dependency order, plus `tasks/<name>/plan.md` indexing them. Blocker tasks get the low numbers. ## Scope of This Skill `get-tasks` is deliberately comprehensive. It absorbs what several narrower skills each did partially, so that a user only needs one skill to go from an approved PRD to a tracked, executable plan. Everything in here is relevant to that single job: | Concern | Where it is handled | |---|---| | Reading the PRD and extracting commitments | Phase 1 | | Dependency structure and ordering | Phase 2 | | Vertical slicing and tracer bullets | Phase 3 | | Wide refactors (expand, migrate, contract) | Phase 3 | | Per-task specification | Phase 4 | | Sizing and splitting rules | Phase 5 | | Checkpoints and gates | Phase 5 | | Parallelization classification | Parallelization Taxonomy | | Human-readable plan summary, risks, decisions | Phase 6 | | Tracker vs. file target | Task List Target | | User approval before writing | Phase 7 | | Writing, syncing, and verifying artifacts | Phase 8 | | Handling failure and replanning | Replanning When a Task Fails | It is long by design. The length is the point: a breakdown that leaves any of these implicit produces tasks that look finished and are not. If you are tempted to skim to the template, read Phases 2, 3, and 5 instead — those are where breakdowns actually fail. What this skill does **not** do: it does not write code, does not run the tasks, and does not replace the PRD. It converts one document into a set of documents. ## When to Use Use this skill when: - A PRD, spec, or requirement document exists and the work needs to become executable tasks - The user says "get tasks", "breakdown PRD", "pecah jadi task", "bikin task list", or "turn this into tasks" - A task feels too large to start and needs decomposing - You need to estimate scope, order the work, or find what can run in parallel - You are about to implement something that touches more than a handful of files and no task list exists **When NOT to use:** - No PRD or spec exists yet — run `get-prd` first, or `spec-driven-development`, then come back - The change is a single task by any measure (one file, one obvious edit) — just do it - The user wants tasks and then immediate execution in one breath — still run this skill, but hand off to `incremental-implementation` at the end rather than implementing inside `get-tasks` - A task list already exists and the user wants to execute it — go straight to `incremental-implementation` ## The Process `get-tasks` runs in nine phases. Each phase has an exit condition. Do not advance past a phase whose exit condition is unmet. ``` 0. Locate the PRD -> which document is the source? 1. Read and extract -> what does the PRD commit us to? 2. Dependency graph -> what depends on what? 3. Vertical slices -> tracer bullets, not horizontal layers 4. Write each task -> one file per task, fully specified 5. Order, size, checkpoint -> sequence, size, and verification gates 6. Write the plan doc -> the human-readable summary that indexes the tasks 7. Quiz the user -> granularity, blocking edges, merge or split 8. Write and verify -> files on disk, todos synced, validators green ``` **Planning is read-only.** Phases 0 through 7 produce documents and questions, not code. Do not create, edit, or delete any source file during those phases. Writing task files under `tasks/` is the only filesystem change allowed before the user approves. If you find yourself fixing a bug or adding a function while breaking down work, stop: that is Phase 8 territory, or it is `incremental-implementation` territory, and it belongs to a task you have not written yet. --- ### Phase 0: Locate the PRD Find the source document before doing anything else. 1. **Convention first.** `get-prd` saves to `docs/prd/<name>.md`. Look there first. 2. **Then the wider search.** If `docs/prd/` is empty, look for `SPEC.md`, `docs/SPEC.md`, or a PRD the user names. Accept a spec, an issue body, or a pasted requirements document — the skill is not format-bound, only the extraction in Phase 1 assumes the PRD section names. 3. **If more than one candidate exists**, do not guess. List them and ask which one governs this work. 4. **If none exists**, stop and say so. Do not invent requirements. Route the user to `get-prd` (for a full interview-to-PRD pass) or `spec-driven-development` (for a spec). Record the exact path you are working from. Every later phase references it. For a **multi-module initiative** where the PRD is split by module id (`docs/prd/identity.md`, `docs/prd/billing.md`), confirm which module this breakdown covers. One breakdown per module, in the build order the capability map declared. **Exit condition:** a single source document is identified, and its path is on the record. --- ### Phase 1: Read and Extract Read the PRD in full. Then extract, explicitly, the material that drives decomposition: | PRD section | What you extract from it | |---|---| | Objective | The end state every task ultimately serves | | User Stories | The observable behaviours that must work, candidate acceptance criteria | | Technical Decisions | Modules, interfaces, schema changes, contracts — these define real boundaries between tasks | | Project Structure | Where artifacts land, which constrains "files likely touched" | | Commands | The concrete verification commands each task will cite | | Testing Strategy | What counts as a good test here, and where tests belong | | Boundaries | Always / Ask First / Never — Never items become hard constraints on every task | | Out of Scope | Explicit non-goals; nothing here becomes a task | | Success Criteria | The final gate; the last checkpoint verifies against it | Rules: - **Do not start slicing yet.** Extraction first, decomposition second. Slicing while reading produces tasks shaped by the order you happened to read the document in. - **Convert vague items into checkable statements.** If the PRD says "the dashboard should be fast", the task's acceptance criterion is a number, and if the PRD gave no number, surface it as a blocker rather than choosing one silently. - **Flag gaps.** If a Needed section is missing or empty, name it. A missing Testing Strategy means every task's verification block will be invented later; raise it now. - **Never invent requirements.** If the PRD does not say it, it is not a task. **Exit condition:** the extraction table is populated, and any gap has been raised with the user. --- ### Phase 2: Map the Dependency Graph Before writing a single task, map what depends on what. This is the phase that determines the order and prevents the most expensive class of mistake: building a consumer before its producer exists. Draw the graph. Concrete, not abstract: ``` Database schema | +-- API models and types | | | +-- API endpoints | | | | | +-- Frontend API client | | | | | +-- UI components | | | +-- Validation logic | +-- Seed data and migrations ``` Rules: - **Edges point producer to consumer.** An arrow means "the target needs the source first". - **No cycles.** If two things each need the other, they are one task, or the interface between them must be defined first as its own task. - **Interfaces are boundaries.** When two tasks meet at a contract (a type, an endpoint shape, a schema), define the contract in the earlier task and consume it in the later one. Never let both tasks invent it independently. - **Find the frontier.** The frontier is every task whose blockers are all done. It is what can start now. For a linear chain the frontier is one task wide; for a wide project it may be several. - **Name the parallel opportunities and the hard sequences.** Independent slices can run in parallel. Migrations, shared state changes, and anything touching the same contract must be sequential. **Exit condition:** a dependency graph exists, with a clear frontier, and no cycles. --- ### Phase 3: Slice Vertically Cut the work into **tracer bullets**: narrow but complete paths through every layer the feature needs. **Horizontal slicing is the default mistake.** It looks tidy and produces nothing runnable until the last task: ``` Bad (horizontal): Task 1: Build the entire database schema Task 2: Build all API endpoints Task 3: Build all UI components Task 4: Connect everything ``` At the end of Task 3, nothing works. Nobody can demo anything. A wrong assumption in Task 1 is discovered in Task 4. **Vertical slicing produces working software at every step:** ``` Good (vertical): Task 1: A user can create an account (schema + API + UI for registration) Task 2: A user can log in (auth schema + API + UI for login) Task 3: A user can create a task (task schema + API + UI for creation) Task 4: A user can view the task list (query + API + UI for list view) ``` Rules for a good slice: - **It cuts through every layer the behaviour needs** — data, logic, interface, test. - **It is demoable or verifiable on its own.** If you cannot describe how to confirm it works, it is not a slice. - **It fits in one focused session** — roughly one fresh context window. - **It delivers behaviour, not structure.** "Add the users table" is not a slice; "a user can register" is. **Wide refactors are the exception.** A wide refactor is one mechanical change (rename a column, retype a shared symbol) whose blast radius fans across the whole codebase, so no vertical slice can land green. Do not force it into a tracer bullet. Sequence it as **expand, migrate, contract**: 1. **Expand** — add the new form beside the old so nothing breaks. 2. **Migrate** — move call sites over in batches sized by blast radius (per package, per directory), each batch its own task blocked by the expand, keeping the build green batch to batch because the old form still exists. 3. **Contract** — delete the old form once no caller remains, in a task blocked by every migrate batch. When even the batches cannot stay green alone, keep the same sequence but let them share an integration branch that all block a final integrate-and-verify task, where green is promised. **Exit condition:** every piece of work belongs to exactly one task, and every task is a vertical slice or a declared wide-refactor step. --- ### Phase 4: Write Each Task Write each task as its own file. One task per file, always — never a single combined document with all tasks inside. **Output path:** `tasks/<name>/task-NN.md`, where `<name>` matches the PRD's name (so a PRD at `docs/prd/billing.md` produces `tasks/billing/task-01.md`). Number from `01`, in dependency order — blockers get the low numbers. **Task file template:** ```markdown # Task NN: <Short descriptive title> **Source:** docs/prd/<name>.md — <PRD section this task implements> **What to build:** The end-to-end behaviour this task makes work, from the user's perspective. Not a layer-by-layer implementation list. If you cannot describe it as behaviour a user or caller can observe, reshape the task. ## Acceptance criteria - [ ] <specific, testable condition> - [ ] <specific, testable condition> Every criterion must be checkable by someone who did not write the task. "Works correctly" is not a criterion. "A user can register with an email and password and is redirected to the dashboard" is. ## Verification - [ ] Tests pass: <the repository's focused-test command> - [ ] Build succeeds: <the repository's build command> - [ ] Output matches: <expected pattern or artefact that must exist> - [ ] No regressions: <the full suite or the relevant subset> - [ ] Manual check: <what a human confirms by looking or clicking> Run these in order. Do not mark the task complete on a partial pass. ## Blocked by <Task numbers that must be complete first, or "None — can start immediately"> ## Files likely touched - `path/to/file` - `path/to/test` This list is an estimate, not a boundary. Discovering a file outside it is expected; silently editing an unrelated one is not. ## Estimated scope <XS: 1 file | S: 1-2 files | M: 3-5 files | L: 5-8 files | XL: too large, split> ## Rollback <How to undo this task if it turns out wrong: the revert command, the feature flag to disable, or the migration's down direction. If there is no rollback, say so explicitly — that is a risk worth surfacing.> ## Notes <Optional. Decisions taken during breakdown, open questions, links to the PRD sections that constrain this task.> ``` Rules for filling it: - **Source line is mandatory.** It makes the task auditable: every task must trace to a PRD section. A task that traces to nothing is scope creep. - **Acceptance criteria are per-task and testable.** They answer "did we build the right thing?", while the project-wide `../../references/definition-of-done.md` answers "is it done to our standard?". Both apply. - **Verification lists all five types, not just tests.** A task that only runs tests can still ship broken output; the manual check and the output-match check catch what tests miss. - **Rollback is not optional.** Writing "not applicable" is fine; leaving it blank is not. - **No code snippets and no specific line numbers.** They go stale. Exception: if a decision is more precisely expressed as a type shape, schema, or state machine than as prose, inline just that fragment and note it encodes a decision. - **Never reference another task file by path.** Reference it by number (`Task 03`) so a rename does not break the chain. **Exit condition:** every task from Phase 3 has a complete file, with no blank template sections. --- ### Phase 5: Order, Size, and Checkpoint Arrange the tasks so the sequence is correct and the risk is early. **Ordering rules:** 1. **Dependencies are satisfied.** Producer tasks come before consumer tasks. This is the graph from Phase 2, not perceived importance. 2. **Each task leaves the system in a working state.** Nothing lands half-migrated into a broken build unless it is a declared wide-refactor step sharing an integration branch. 3. **High-risk tasks go early.** Fail fast: a risky assumption discovered in Task 2 is cheap; discovered in Task 12 it is expensive. 4. **Prefactoring goes first.** "Make the change easy, then make the easy change." A task that prepares the ground gets a low number. **Sizing rules:** | 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** | 5-8 | Multi-component feature | Search with filtering and pagination | | **XL** | 8+ | **Too large — split it** | — | An agent performs best on S and M. Break any task that is L or larger. **When to split a task further:** - It would take more than one focused session (roughly two hours of agent work). - You cannot state the acceptance criteria in three bullet points or fewer. - It touches two or more independent subsystems (for example auth and billing). - You wrote "and" in the title — that is two tasks. **Checkpoints.** Insert a checkpoint after every two to three tasks. A checkpoint is not a task; it is a gate. Write it as its own file `tasks/<name>/checkpoint-NN.md`: ```markdown # Checkpoint NN: after Tasks <a>-<b> - [ ] All tests pass - [ ] The build succeeds with no errors - [ ] The core flow works end-to-end - [ ] No task left half-done - [ ] Human review before proceeding If any item fails, stop and fix before continuing. Checkpoints exist so a wrong assumption costs one checkpoint instead of the whole plan. ``` Place a final checkpoint that verifies the PRD's **Success Criteria** directly, section by section. **Exit condition:** every task has a number, a size, and a place in the sequence; checkpoints are placed; the final checkpoint maps to the PRD's success criteria. --- ### Parallelization Taxonomy Before writing the plan document, classify the tasks by how they may run. Agents and humans both parallelize badly by default, so make the classification explicit rather than leaving it to whoever picks up the work. | Category | Meaning | Examples | |---|---|---| | **Safe to parallelize** | No shared state, no shared contract, independent failure domains | Independent feature slices, tests for already-implemented code, documentation | | **Must be sequential** | Ordering is load-bearing; running early corrupts state or breaks the build | Database migrations, shared state changes, dependency chains, schema edits | | **Needs coordination** | Parallelizable only after a shared decision is frozen | Features that share an API contract — define the contract first, then parallelize | Rules: - **A task is in exactly one category.** If it looks parallelizable but touches a contract another task also touches, it is "needs coordination" until the contract is frozen. - **Record the classification in the plan document**, per task or per phase. - **Coordination tasks get an explicit prerequisite task** that defines the shared contract. That prerequisite is sequential by definition. --- ### Phase 6: Write the Plan Document The task files are the executable units. The plan document is the human-readable summary that indexes them and records what the task files deliberately omit: design decisions, risks, and unresolved questions. Write `tasks/<name>/plan.md`: ```markdown # Implementation Plan: <Project or Feature Name> ## Overview One paragraph. What this breakdown covers, and which PRD it came from (`docs/prd/<name>.md`). ## Architecture Decisions - <Decision and the reasoning that produced it> - <Decision and the reasoning that produced it> These are the decisions taken during breakdown that the PRD left open or that only became visible once the work was sliced. Anything already settled in the PRD's Technical Decisions section is not repeated here. ## Phases ### Phase 1: <Foundation | Core | Polish | ...> - [ ] Task 01: <title> - [ ] Task 02: <title> **Checkpoint:** <what must be true before Phase 2 starts> ### Phase 2: <...> - [ ] Task 03: <title> **Checkpoint:** <what must be true before Phase 3 starts> ### Phase 3: <...> - [ ] Task NN: <title> **Final checkpoint:** every Success Criterion from the PRD is verified. ## Parallelization | Task | Category | Notes | |---|---|---| | 01 | Must be sequential | Defines the schema everything else reads | | 02 | Safe to parallelize | Independent slice | | 03 | Needs coordination | Shares the billing contract with 04 - freeze it first | ## Risks and Mitigations | Risk | Impact | Mitigation |