--- name: prd-to-kanban description: Break a PRD (Product Requirements Document) down into small, self-contained tasks organized as a file-based kanban board, designed so multiple AI agents can execute tasks in parallel. Each task is its own Markdown file. Use this skill whenever the user asks to turn a PRD, spec, or requirements document into tasks, tickets, a backlog, a kanban board, or a parallelizable work breakdown — even if they don't say "kanban". Also use it right after generating a PRD when the user asks "now split this into tasks" or "plan the implementation". --- # PRD to Kanban (parallel-ready tasks) Transform a PRD into a set of small, self-contained task files organized in a kanban-style directory structure. The board lives entirely in the repo as plain Markdown (git-friendly, reviewable in PRs), and tasks are written so that **multiple AI agents can pick up different tasks and work on them simultaneously** — in separate sessions, subagents, or git worktrees — without stepping on each other. ## The parallelism contract Every task must satisfy these rules. They are the core of this skill: 1. **Self-contained.** An agent must be able to complete the task by reading *only* that one task file plus the repo. Never write "see task 003 for details" or assume knowledge from the PRD — copy the relevant context into the task. 2. **Exclusive file ownership.** Each task declares the files it will create or modify in a `files` field. **No two tasks in the same wave may touch the same file.** This is what makes parallel execution merge-conflict-free. If two pieces of work need the same file, either merge them into one task or put them in different waves. 3. **Explicit interfaces.** When task B builds on task A's output, the *interface* (function signature, API route, type, CLI contract, table schema) is decided now and written into **both** task files. Agents implement against the contract, not against each other's unpredictable output. 4. **Waves, not chains.** Group tasks into numbered waves: all tasks in wave 1 can run at the same time with zero dependencies; wave 2 tasks depend only on wave 1; and so on. Maximize the width of each wave and minimize the number of waves. 5. **Independently verifiable.** Each task's acceptance criteria must be checkable without any other in-flight task being finished (its dependencies from earlier waves are assumed done). ## Workflow 1. **Locate the PRD.** If the user points to a file, read it. Otherwise look for `prd-*.md` in `docs/`, `tasks/`, or the repo root. If several exist, ask which one. If none exists, suggest running the `write-prd` skill first. **If the "PRD" is really a single trivial change** (one obvious edit, no new contracts, no parallelism), a one-task board is overkill — tell the user to use the `quick-task` fast path instead of building ceremony. 2. **Extract the work.** Go through the PRD section by section — especially Functional Requirements, Non-Functional Requirements, UX Notes, Technical Considerations, and Milestones. Every requirement must map to at least one task; no requirement may be silently dropped. 3. **Split into small tasks.** Each task should take one agent roughly ≤2 hours of focused work. Prefer more, smaller, independent tasks over fewer large ones — small tasks are what create parallelism. 4. **Design the interfaces.** Before writing any task file, sketch the shared contracts (types, function signatures, routes, schemas) and the file-ownership map. Adjust task boundaries until no wave has overlapping files. 5. **Consult module memory.** For each file a task will own, check `knowledge/INDEX.md` (the `close-cycle` memory) for a matching entry. Load any recorded decisions, gotchas, patterns, and contracts for that unit, and **fold the relevant ones directly into the task file** (its Context / Interfaces / Edge cases) — don't just link them. List each memory file consulted in the task's `memory_refs`. The point is that the executor receives the accumulated wisdom without needing to open the memory itself. 6. **Assign waves** based on the dependency graph. 7. **Create the board structure** and write one file per task using the template. Pin down every implementation fork *here*, so the executor decides as little as possible (see Task-splitting guidelines). 8. **Write `BOARD.md`** with the wave-based execution plan, and report a summary to the user: number of tasks, number of waves, maximum parallelism per wave, and any ambiguous requirements. Do not start implementing any task. This skill produces the board only. ## Board structure ALWAYS use this layout, inside the same directory where the PRD lives (e.g. `docs/`), in a folder named after the PRD: ``` kanban-/ ├── BOARD.md ├── backlog/ │ ├── 101-csv-serializer.md # wave 1 → IDs 1xx │ ├── 102-permission-check.md │ ├── 201-export-button-ui.md # wave 2 → IDs 2xx │ └── ... ├── in-progress/ └── done/ ``` - All tasks start in `backlog/`. Moving a task between columns = moving the file between folders (`git mv`), which keeps history clean. - File names: `WNN-kebab-case-title.md`, where the first digit is the **wave** and the last two digits number the task within the wave. The ID encodes the parallel schedule at a glance and never changes when files move between columns. ## Task file template ALWAYS use this exact structure for each task: ```markdown --- id: 201 title: Add "Export CSV" button to reports page status: backlog wave: 2 depends_on: [101, 102] # ids from earlier waves only, or [] priority: high # high | medium | low estimate: S # XS (trivial) | S (≤1h) | M (≤2h) — drives how much detail below files: # files this task OWNS (creates or modifies) - src/pages/Reports.tsx - src/pages/Reports.test.tsx prd_refs: [FR-1, FR-2] memory_refs: # knowledge/ module-memory files folded in (or []) - knowledge/reports/reports-page.md agent_ready: true # false if the task still has open questions --- # 201 – Add "Export CSV" button to reports page ## Context (self-contained) Everything an agent needs to know, restated here even if it repeats the PRD: what the feature is, why this task exists, and how it fits the whole. Assume the agent has NOT read the PRD or any other task. Paste the CURRENT state of the code you're changing (real excerpts with `file:line`) so the agent starts from fact, not a guess. ## Interfaces you must conform to Contracts shared with other tasks, stated exactly: - Call `serializeReportToCsv(report: Report): string` from `src/lib/csv.ts` (implemented in task 101 — assume it exists and works). - Gate the button behind `canExportReports(user)` from `src/lib/permissions.ts` (task 102). ## Implementation plan Prescriptive, ordered steps that leave the executor as little to decide as possible. Name the exact functions/methods/components, their signatures, and WHERE each goes (file + section/line). **If there's a fork — getter vs method, inline vs helper, which util to call — PICK ONE here; never pass the choice to the executor.** Reference real file paths. Stay strictly within the files listed in `files`; if you find you must edit another file, STOP and report back. 1. In `src/pages/Reports.tsx`, add `handleExport(): void` — calls `serializeReportToCsv(report)`, then downloads via `downloadBlob()` from `src/lib/download.ts`. 2. Render `