PRD to Issues
Intent
Use this skill when a PRD already exists and the user wants to turn it into a concrete, executable plan: a set of issues or tasks that multiple people (or agents) can pick up independently.
The goal is to break work into thin vertical slices that cut through layers (API, logic, UI, data) rather than horizontal refactors of a single layer.
Inputs
- A PRD (in the conversation, a file, or a GitHub issue).
- Access to the repository to explore relevant code.
Workflow
Locate and read the PRD
- If given a link or path, fetch and summarize the PRD.
- Confirm with the user that this is the correct and current document.
Extract major capabilities
- Identify the main user-facing capabilities or flows described by the PRD.
- Summarize them as a short list, for example: “search results page”, “saved filters”, “admin analytics”.
Explore the codebase
- For each capability, scan for relevant modules, APIs, or components.
- Note:
- Where new functionality will plug in
- Existing patterns worth reusing
- Areas of high risk or uncertainty
Draft vertical slices
- For each meaningful increment of user-visible value, draft an issue that:
- Delivers a thin end-to-end slice (backend to UI, where applicable).
- Minimizes unknowns by touching the riskiest or least-understood part early (“tracer bullets”).
- Avoid issues that are purely “backend groundwork” or “UI only” unless truly necessary.
Define blocking relationships
- For each issue, decide whether it:
- Can be done independently, or
- Is blocked by another issue’s completion.
- Express dependencies clearly in the issue text (for example: “Blocked by: #123” or a simple list in the summary you output).
Propose issue set
- For each issue, include at least:
- Title: short, action-oriented.
- Summary: 2–4 sentences including the user story it serves.
- Scope: bullet list of concrete tasks / files / modules.
- Blocking / blocked-by: references to other issues in the set.
Optional: create GitHub issues
- If the user confirms they want GitHub issues created and provides conventions (labels, assignees, projects), follow them.
- Otherwise, output the issues in a copy-pasteable format.
Style Guidelines
- Prefer fewer, deeper issues over many tiny ones that lack meaningful value.
- Make sure at least one issue is unblocked so work can start immediately.
- Call out any unknown unknowns you discover while exploring the codebase and create explicit spikes or investigation tasks if needed.
- Keep descriptions just detailed enough that another engineer could pick up an issue without re-reading the entire PRD.
1---2name: prd-to-issues3description: Convert a Product Requirements Document into a Kanban-friendly set of vertical-slice issues with clear blocking relationships, grounded in the existing codebase and optimized for parallel work.4---56# PRD to Issues78## Intent910Use this skill when a PRD already exists and the user wants to turn it into a concrete, executable plan: a set of issues or tasks that multiple people (or agents) can pick up independently.1112The goal is to break work into **thin vertical slices** that cut through layers (API, logic, UI, data) rather than horizontal refactors of a single layer.1314## Inputs1516- A PRD (in the conversation, a file, or a GitHub issue). 17- Access to the repository to explore relevant code.1819## Workflow20211. **Locate and read the PRD**22 - If given a link or path, fetch and summarize the PRD. 23 - Confirm with the user that this is the correct and current document.24252. **Extract major capabilities**26 - Identify the main user-facing capabilities or flows described by the PRD. 27 - Summarize them as a short list, for example: “search results page”, “saved filters”, “admin analytics”.28293. **Explore the codebase**30 - For each capability, scan for relevant modules, APIs, or components. 31 - Note: 32 - Where new functionality will plug in 33 - Existing patterns worth reusing 34 - Areas of high risk or uncertainty35364. **Draft vertical slices**37 - For each meaningful increment of user-visible value, draft an issue that: 38 - Delivers a thin end-to-end slice (backend to UI, where applicable). 39 - Minimizes unknowns by touching the riskiest or least-understood part early (“tracer bullets”). 40 - Avoid issues that are purely “backend groundwork” or “UI only” unless truly necessary.41425. **Define blocking relationships**43 - For each issue, decide whether it: 44 - Can be done independently, or 45 - Is blocked by another issue’s completion. 46 - Express dependencies clearly in the issue text (for example: “Blocked by: #123” or a simple list in the summary you output).47486. **Propose issue set**49 - For each issue, include at least: 50 - **Title**: short, action-oriented. 51 - **Summary**: 2–4 sentences including the user story it serves. 52 - **Scope**: bullet list of concrete tasks / files / modules. 53 - **Blocking / blocked-by**: references to other issues in the set.54557. **Optional: create GitHub issues**56 - If the user confirms they want GitHub issues created and provides conventions (labels, assignees, projects), follow them. 57 - Otherwise, output the issues in a copy-pasteable format.5859## Style Guidelines6061- Prefer **fewer, deeper** issues over many tiny ones that lack meaningful value. 62- Make sure at least one issue is unblocked so work can start immediately. 63- Call out any **unknown unknowns** you discover while exploring the codebase and create explicit spikes or investigation tasks if needed. 64- Keep descriptions just detailed enough that another engineer could pick up an issue without re-reading the entire PRD.65
spicy-samson