Prd to tickets

PRD to Tickets

Generate implementation-ready tickets from an existing Product Requirements Document.

What this skill does

Takes an existing PRD — a local markdown — and produces individual implementation tickets as markdown files.

---

Step 1: Locate and read the PRD

The PRD can come from several sources. Try them in this order:

Option A: User provides a file path

If the user explicitly points to a file, use that. Supported formats:

• Markdown files (.md): Read directly using the Read tool.

Option B: Auto-detect local file

Check these locations in the current working directory:

1. PRD.md
2. Any prd-*.md file in the current directory or nearby

Option C: Ask the user

If no PRD is found locally, ask the user: "I can't find a PRD file. Do you have a file path to the PRD (markdown)?"

After loading

Read the PRD thoroughly. Understand the phases, user stories, data model, and scope boundaries before generating any tickets.

If the PRD is unclear or has open questions that affect ticket breakdown, flag them to the user before proceeding.

---

Step 2: Plan the ticket breakdown

Before writing tickets, outline the breakdown to the user:

• How many tickets per phase
• The dependency order
• Whether backend/frontend splits make sense for each piece

Get a quick confirmation before writing all the tickets. This avoids rework if the user has a different mental model of how the work should be split.

---

Step 3: Generate implementation tickets

Ticket philosophy

The tickets should be usable as project issues that an LLM or engineer can pick up and implement independently. Each ticket should be self-contained enough that someone (or an AI coding agent) can understand what to build, how to verify it, and what "done" looks like — without needing to read the entire PRD.

Ticket structure

Use this as a guideline, not a rigid template. Adapt based on the project's norms and the ticket's complexity.

# [Ticket Title]

**Phase:** [Which phase this belongs to]
**Type:** [Backend / Frontend / Full-stack / Infrastructure / Design]
**Priority:** [P0-P3 or High/Medium/Low]
**Depends on:** [Other ticket titles, if any]

## Context

Why this ticket exists. Brief background — enough that someone picking this up cold understands the motivation. Reference the PRD if needed.

## Requirements

What needs to be built. Be specific about behaviour, not implementation. Include:

- Functional requirements (what it does)
- Technical constraints (must use X pattern, must integrate with Y)
- Scope boundaries (what this ticket does NOT include)

## Acceptance Criteria

Concrete, testable conditions that must be true when this ticket is done.
Write these as checkable statements:

- [ ] User can [action] and sees [result]
- [ ] API returns [shape] when [condition]
- [ ] Error state [X] displays [message]

## Feature Tests

Describe the test scenarios that should be written as part of this ticket. Be specific about setup, action, and expected outcome. For example:

- **Test:** [Descriptive name]
  - **Setup:** [Preconditions]
  - **Action:** [What happens]
  - **Expected:** [What should result]

## Notes

Implementation hints, links to relevant code, design references, or anything else that helps. Optional.

Splitting tickets

The default approach is to split backend and frontend work into separate tickets when the feature involves both, since this makes code review and deployment simpler. But use judgment — a tiny full-stack change that's easier to review as one unit should stay as one ticket.

Group tickets by phase. Within a phase, order them by dependency (things that need to be built first come first).

The overarching ticket

In addition to individual implementation tickets, create one overarching "epic" ticket that:

• Summarises the entire feature
• Lists all child tickets in order, grouped by phase
• Includes a high-level dependency graph (which tickets block others)
• Links to the PRD

This is the ticket a project manager or tech lead uses to track the whole feature.

---

Step 4: Save tickets locally

Save ticket files alongside the PRD. If the PRD is at PRD.md, save tickets into a tickets/ subdirectory in the same location.

File naming

tickets/00-epic-[feature-name].md  — The overarching epic ticket
tickets/01-[short-name].md         — First implementation ticket
tickets/02-[short-name].md         — Second implementation ticket
...

Use kebab-case for file names. Number tickets in dependency/phase order so they read naturally.

---

Tips for writing good tickets

• Be specific about behaviour, not implementation. "The user sees a filterable table of agents" is better than "Render a React table component with useFilter hook." Tickets define what to build with enough context on how to get started.
• Acceptance criteria should be falsifiable. If you can't write a test for it, it's not a real acceptance criterion.
• Feature tests are first-class citizens. They limit ambiguity and tell the implementer exactly how to verify their work. Don't skimp on them.
• Use the user's language. If they call it an "agency," don't rename it to "organization" in the tickets. Consistency with the codebase and team vocabulary reduces friction.
• Flag open questions explicitly. It's better to say "Decision needed: should soft-delete or hard-delete?" than to silently pick one.