# Prd Todo Slicer > Break a PRD.md into a small, deterministic TODO.md queue and per-task briefs that sub-agents can execute safely one task at a time. - Skill: `aaronflorey/prd-todo-slicer` (Agent Skill) - Install (CLI): `npx skillmds@latest add aaronflorey/prd-todo-slicer` - Raw SKILL.md: https://api.skillmd.com/api/skills/aaronflorey/prd-todo-slicer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: MIT - Author: aaronflorey (https://skillmd.com/u/aaronflorey) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/aaronflorey/prd-todo-slicer --- ## What I do Use this skill when the user asks to break a `PRD.md`, product spec, approved implementation plan, or requirements document into an implementation queue. The output is a lightweight `TODO.md` plus optional detailed task brief files. The queue must be small-slice, deterministic, reviewable, and safe for a focused sub-agent to execute without making product or architecture decisions. Do not implement product code while using this skill. Produce planning files only. ## Default output layout Prefer this layout unless the user requests a single-file TODO: ```text TODO.md .planning/ TODO-TRACE.md todos/ P1-T1.md P1-R1.md P2-T1.md P2-R1.md ``` Use `TODO.md` as the queue and status tracker. Put task-specific context in `.planning/todos/.md` so the active executor can load one brief without reading a huge TODO file. If the repository already uses a different planning directory, keep the existing convention and adapt the paths. ## Required inputs Read these before writing tasks: 1. `PRD.md` or the PRD path supplied by the user. 2. Any approved implementation plan, architecture note, or design decision document in `.planning/`. 3. Existing repository structure, package manager, test commands, lint commands, typecheck commands, and framework conventions. 4. Existing TODO files, if present, so completed work is preserved rather than duplicated. If `PRD.md` is missing, unreadable, or contradicts an approved plan, stop and report the exact blocker. Do not invent requirements. When a `prompt-engineer` skill or prompt-quality reference is available, use it only as a clarity check for generated task briefs. Each brief should make role/context, task, constraints, acceptance criteria, checks, stop conditions, and report expectations explicit enough for a sub-agent to follow without rereading the full PRD. ## Clarification interview Before writing or updating requirements, TODO rows, task briefs, or traceability, identify every PRD ambiguity that could cause an implementation agent to make the wrong product, architecture, API, security, storage, dependency, UX, or verification decision. Interview the user relentlessly only on those implementation-risk ambiguities. Do not ask questions for the sake of asking. Do not ask about details that are already resolved by the PRD, approved plans, explicit user arguments, or strong existing repository conventions. For each necessary question: - Use the `question` tool when available. - Ask one decision at a time when the answer affects later questions. - Explain the ambiguity and the concrete implementation risk. - Provide your recommended answer as the first option and label it `(Recommended)`. - Include concise alternatives when they are viable. - Use the answer to resolve dependent branches of the design tree before moving on. Continue until the remaining PRD is clear enough to produce requirements and task briefs that an executor can implement without guessing. If the user declines to decide or an ambiguity cannot be resolved, create a blocked decision task instead of hiding the choice inside an implementation task. ## Slicing standard Every implementation task must be executable by one sub-agent in one focused run. A task is too large if any of these are true: - It combines unrelated concerns, such as schema design plus UI plus persistence. - It requires an unapproved product, API, security, storage, or architecture decision. - It touches more than one feature area unless the coupling is unavoidable and explicitly explained. - It cannot be verified with concrete checks or inspection steps. - Its objective needs words like “finish”, “wire up everything”, “polish”, “support”, “integrate”, “make robust”, or “implement the system”. - It has more than seven acceptance criteria. - It depends on behavior not already present in the PRD, approved plan, or repository conventions. When a task is too large, split by this order: 1. Contracts and types. 2. Pure validation or state logic. 3. Core behavior with tests. 4. Persistence or IO boundary. 5. Adapter or framework integration. 6. UI or CLI surface. 7. Error handling and edge cases. 8. Documentation or migration notes. 9. Final review and verification. ## Blocker policy Plan to keep implementation moving. A TODO should block only when it needs a human-level decision that is not already resolved by the PRD, an approved plan, current-session user instructions, or strong repository conventions. Real blockers include unapproved changes to product behavior, public API or CLI contracts, persistence or migrations, security posture, dependency or tooling choices, architecture boundaries, external integrations, or user-facing UX decisions. Do not turn normal implementation work into blockers. Executors should repair or adapt within the active TODO when they encounter: - Expected-file lists that are stale, incomplete, duplicated, or too narrow. - Adjacent files that must change to wire the requested behavior into the project. - Missing helper files, interfaces, constructors, tests, fixtures, or seams that can be added using existing conventions. - Failing tests or checks caused by the active implementation. - Existing generated files or generated equivalents that should be reused instead of duplicated. - Planning state that is stale but can be refreshed from `.planning/TODO.md`, `.planning/PRD.md`, the detailed brief, git status, and current repository evidence. When an executor edits outside the expected file list, it must keep the change directly tied to the active TODO and report the file plus rationale. When a needed outside-file edit would change one of the real-blocker areas above, make that a decision task instead of hiding it inside an implementation task. ## Generated artifact policy Generated artifacts are repository evidence. If a generator or previous task already produced the class, type, interface, fixture, schema, mock, or file needed by the active TODO, the executor should reuse or adapt references to that artifact instead of creating a duplicate. Create a blocker only when choosing or changing the generated artifact would alter product behavior, public contracts, storage, security, architecture, dependencies, or generator configuration beyond what the PRD or approved plan already allows. ## Task ID rules Use stable IDs: - `P-T` for implementation tasks. - `P-R` for review tasks. - `P-V` only when verification is complex enough to deserve a separate task. - `P-D` for blocked decision tasks that require user approval before implementation. Examples: `P1-T1`, `P1-R1`, `P2-D1`. Phases must represent dependency order, not calendar time. Earlier phases should unblock later phases. ## Planning workflow Follow this process exactly: 1. Read the PRD fully and list the product outcomes, non-goals, constraints, user-visible behaviors, data/state requirements, integrations, and verification requirements. 2. Inspect the repository enough to identify current structure, package manager, language, test commands, and naming conventions. 3. Run the clarification interview for implementation-risk ambiguities and record resolved decisions in the generated planning artifacts. 4. Convert PRD requirements into a dependency graph. Put prerequisites first: project skeleton, schemas, types, state, core logic, adapters, interfaces, then documentation. 5. Create phases around natural gates. Each phase should end with a review task. 6. Create implementation tasks that each have one objective, expected starting files, acceptance criteria, checks, blocker policy, generated-artifact policy, and stop conditions. File lists should guide the executor, not block directly necessary adjacent-file edits. 7. Create review tasks after meaningful implementation groups. Review tasks must compare implementation against the task brief, PRD, and approved plan. 8. Create decision tasks for unresolved choices. Mark them `blocked`; do not hide decisions inside implementation tasks. 9. Write `TODO.md` as a compact queue summary and status tracker. 10. Write one detailed brief file per task under `.planning/todos/`. 11. Write `.planning/TODO-TRACE.md` mapping PRD requirements to task IDs and listing unresolved decisions. 12. Run a final planning quality pass: no vague tasks, no hidden decisions, no duplicate work, no unverified requirements, no orphan PRD requirements. ## TODO.md requirements `TODO.md` must stay lightweight. Include these sections in this order: 1. Title. 2. Purpose statement. 3. Status values. 4. Current progress. 5. Operating rules. 6. Sub-agent responsibilities. 7. Queue summary table. 8. Detailed brief index. 9. Traceability pointer. Use this status vocabulary only: - `pending`: not started. - `in_progress`: currently active. - `blocked`: waiting on a decision or failed verification. - `complete`: accepted and verified. The queue summary table must include: ```markdown | ID | Status | Objective | Brief | Verification | | --- | --- | --- | --- | --- | | P1-T1 | pending | Create minimal workspace skeleton. | `.planning/todos/P1-T1.md` | Install, test, typecheck, lint. | ``` The `Objective` must be one sentence. The `Verification` cell must name concrete commands or inspection checks. ## TODO.md template Use this template and fill it with project-specific content: ```markdown # TODO This file is the queue and status tracker for . It is not product runtime state. Completion is proven by code, tests, review, verification, and any canonical planning state required by this repository. ## Status Values - `pending`: not started. - `in_progress`: currently active. - `blocked`: waiting on a decision or failed verification. - `complete`: accepted and verified. ## Current Progress Current TODO: none Next recommended TODO: Last update: ## Operating Rules - Work on one TODO per run. - Before editing code, read the matching detailed brief in `.planning/todos/`. - If `.planning/PLAN.md` is used by this repository, rebuild it from the active detailed brief and the approved implementation plan before implementation. - Treat `.planning/PLAN.md` as active execution state, not the PRD source of truth. Use `.planning/PRD.md` or the supplied PRD path for PRD references. - Use focused sub-agents when available: executor for implementation, reviewer for plan/PRD review, verifier for behavior/check validation, repair for focused fixes. - Do not run multiple executor sub-agents against the same TODO at the same time. - The main agent remains responsible for orchestration, final judgement, and state updates. - Do not skip a review TODO after an implementation TODO group. - Do not mark a TODO complete until checks and review/verification pass. - Stop and ask only for unapproved product, public API, persistence, security, dependency, architecture, integration, or UX decisions. Repair normal implementation issues, failing checks, stale expected-file lists, and directly required adjacent-file edits within the active TODO. - Do not commit unless explicitly approved by the user in the current run. ## Sub-Agent Responsibilities - Executor: implement only the active TODO from its detailed brief, make the smallest correct change, and report changed files plus checks run. - Reviewer: check the implementation against the detailed brief, approved implementation plan, and PRD; prioritize correctness, scope drift, missing tests, and regressions. - Verifier: run or inspect the required checks from the detailed brief and confirm acceptance criteria are satisfied. - Repair: fix only focused defects found by review or verification, then return to review/verification. - If sub-agents are unavailable, the main agent must perform implementation, review, and verification as separate labeled passes. ## Queue Summary | ID | Status | Objective | Brief | Verification | | --- | --- | --- | --- | --- | | | pending | | `.planning/todos/.md` | | ## Detailed Brief Index - ``: `.planning/todos/.md` ## Traceability Requirement coverage and unresolved decisions are tracked in `.planning/TODO-TRACE.md`. ``` ## Detailed task brief requirements Each `.planning/todos/.md` file must be self-contained enough for an executor or reviewer to work safely without re-reading the whole PRD. Use this template: ```markdown # : Status: pending Type: implementation | review | verification | decision Phase: Depends on: PRD refs: Approved-plan refs: ## Objective ## Context - - - ## Expected files Start with these expected files. You may create or modify another file only when it is directly required for this TODO, consistent with the PRD and approved plan, and documented in your report: - ``: - ``: ## Required changes 1. 2. 3. ## Non-goals - - ## Acceptance criteria - - - ## Checks Run or inspect: - `` - `` - ## Report requirements The executor must report changed files, any files changed outside the expected list with rationale, checks run, acceptance criteria status, assumptions, and blockers. ## Blocker policy Do not stop just because the expected file list is incomplete, a directly required adjacent file must change, a helper/test/seam is missing, checks fail, or an existing generated artifact should be reused. Make the smallest PRD-consistent change and report the rationale. Stop only if the task needs an unapproved product, public API or CLI, persistence or migration, security, dependency or tooling, architecture, external integration, or UX decision. ## Generated artifacts If a generated artifact or generated equivalent already exists, reuse it or adapt references to it instead of creating a duplicate. Stop only if choosing or changing the artifact would affect a real blocker area. ## Review instructions The reviewer must verify: - The implementation matches this brief and does not add unrequested behavior. - All acceptance criteria are satisfied. - Required tests or checks pass, or failures are explained and unrelated. - No later-phase work was pulled into this task. - Any file changed outside the expected list was directly required, PRD/plan-consistent, and explained. - Existing generated artifacts were reused instead of duplicated when applicable. ## Stop conditions Stop and ask the main agent or user if: - - - ``` ## Review task brief requirements A review task must not implement new feature scope. It should inspect, run checks, and produce a verdict. Review task acceptance criteria must include: - The reviewer compared code against all implementation task briefs in the phase. - The reviewer checked relevant PRD and approved-plan requirements. - The reviewer identified scope drift, missing tests, regressions, and incomplete acceptance criteria. - The reviewer either accepted the phase or created/updated focused repair TODOs. Use review tasks after each phase or after every two to four tightly related implementation tasks. ## Decision task requirements Create a `P-D` task when implementation cannot proceed without a choice. A decision task must include: - The exact unanswered question. - The PRD section or code constraint that exposed it. - The viable options. - The recommended option, if the evidence is strong. - The tasks blocked by the decision. Decision tasks start as `blocked`. Do not let executor sub-agents resolve them independently. ## Traceability file Write `.planning/TODO-TRACE.md` with this structure: ```markdown # TODO Traceability ## PRD Requirement Coverage | PRD area | Requirement | Task IDs | Status | | --- | --- | --- | --- | | | | | covered | pending-decision | missing | ## Phase Dependencies | Phase | Depends on | Unlocks | | --- | --- | --- | | P1 | none | P2 | ## Unresolved Decisions | ID | Question | Blocks | Status | | --- | --- | --- | --- | | P2-D1 | | | blocked | ``` Every PRD requirement must map to at least one task or an explicit unresolved decision. No task should exist without a PRD, approved-plan, or repository-maintenance reason. ## Concrete slicing examples Bad task: ```markdown P2-T1: Implement authentication. ``` Better slices: ```markdown P2-T1: Define authentication config and validation schemas. P2-T2: Implement password credential verification as pure core logic. P2-T3: Add login route adapter using the verified core logic. P2-T4: Add authentication error handling and regression tests. P2-R1: Review authentication implementation against PRD security requirements. ``` Bad task: ```markdown P3-T1: Build dashboard. ``` Better slices: ```markdown P3-T1: Define dashboard data contract and fixture data. P3-T2: Implement dashboard data loader with tests. P3-T3: Render dashboard summary cards from the data contract. P3-T4: Render empty and error states for dashboard data. P3-R1: Review dashboard behavior and UI states against PRD acceptance criteria. ``` ## Language rules Use concrete verbs: - Create - Add - Define - Replace - Move - Remove - Validate - Verify - Review Avoid vague verbs unless followed by exact scope: - Implement - Support - Integrate - Improve - Polish - Harden - Finish - Wire up Replace vague wording with observable outputs. For example, replace “support config” with “define `ConfigSchema` with `mode`, `rootDir`, and `logLevel` defaults, plus schema tests.” ## Final quality checklist Before finishing, verify all of the following: - `TODO.md` is short enough to scan quickly. - Each task has exactly one objective. - Each implementation task has a detailed brief file. - Each implementation task has expected starting files and a narrow allowance for justified adjacent-file edits. - Each implementation task includes a blocker policy that prevents stale expected-file lists, adjacent wiring, missing helpers, generated artifacts, or failing checks from becoming human blockers by default. - Each implementation task defines report requirements for changed files, outside-expected-file rationale, checks, assumptions, and blockers. - Each task has concrete acceptance criteria and checks. - Each phase has a review or verification gate. - Every PRD requirement is covered in `.planning/TODO-TRACE.md`. - Ambiguities are represented as blocked decision tasks. - No task asks a sub-agent to make product or architecture choices. - No task requires reading the full PRD to understand what to do. - No task includes committing changes unless the user explicitly approved commits in the current run.