# Prd To Issues

> 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.

- Skill: `spicy-samson/prd-to-issues` (Agent Skill)
- Install (CLI): `npx skillmds@latest add spicy-samson/prd-to-issues`
- Raw SKILL.md: https://api.skillmd.com/api/skills/spicy-samson/prd-to-issues/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: spicy-samson (https://skillmd.com/u/spicy-samson)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/spicy-samson/prd-to-issues

---


# 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

1. **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.

2. **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”.

3. **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

4. **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.

5. **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).

6. **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.

7. **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.