When you have a PRD (Product Requirements Document) and need to break it into implementable work, the natural instinct is to slice horizontally — "build the database layer," "build the API," "build the UI." This produces issues that can't be demoed or verified independently and creates long integration phases where everything breaks.

The better approach: vertical slices. Each issue cuts through every layer end-to-end, delivering a narrow but complete path that's demoable on its own.

This workflow is adapted from Matt Pocock's skills collection, reshaped for use as a Claude Code prompt.

The workflow

I have a PRD that needs to be broken into GitHub issues. Here's the process I want you to follow:

## 1. Read and internalize the PRD

[Paste your PRD here, or point to a GitHub issue number]

## 2. Explore the codebase

Before proposing any breakdown, read the key modules and integration layers the PRD touches. Identify:

- The distinct layers this feature touches (database/schema, API/backend, UI, tests, config)
- Existing patterns for similar features in this codebase
- Natural seams where work can be parallelized

## 3. Break into vertical slices

Each issue must be a VERTICAL slice that cuts through ALL layers end-to-end. Follow these rules:

- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
- A completed slice is demoable or verifiable on its own
- The first slice is the simplest possible end-to-end path (the "tracer bullet")
- Later slices add breadth: edge cases, additional user stories, polish
- Prefer many thin slices over few thick ones

## 4. Present for review

For each proposed slice, show:
- **Title**: short descriptive name
- **Layers touched**: which integration layers this slice cuts through
- **Blocked by**: which other slices must complete first
- **What it delivers**: what a reviewer can demo or verify when this issue is done

Present this as a numbered list. Ask me:
- Does the granularity feel right?
- Are the dependency relationships correct?
- Should any slices be merged or split?
- Is the first tracer bullet the right starting point?

## 5. Create GitHub issues

After I approve, create each issue using `gh issue create` with this structure:

### Title
[Short descriptive title]

### Body
## Parent PRD
#[prd-issue-number]

## What to build
[Concise description of the end-to-end behavior, not layer-by-layer implementation. Reference specific sections of the parent PRD.]

## Acceptance criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Blocked by
[#issue-number or "None — can start immediately"]

Create issues in dependency order so you can reference real issue numbers in the "Blocked by" field.

After creating all issues, print a summary table:

| # | Title | Blocked by | Status |
|---|-------|-----------|--------|
| 42 | Basic widget creation | None | Ready |
| 43 | Widget listing | #42 | Blocked |

Why vertical slices

Horizontal slices (one layer at a time) seem logical but cause problems:

• You can't verify the database layer works correctly until the UI exists to exercise it
• Integration happens at the end, when all the bugs surface at once
• Issues sit "done" for weeks waiting on other layers before anything is demoable

Vertical slices (thin end-to-end paths) solve this:

• Each issue produces something you can see working
• Integration bugs surface immediately, on the first slice
• The first tracer bullet proves the architecture works before you invest in breadth
• Reviewers can verify each PR independently

Tips

• The first slice should be embarrassingly simple. If your feature is "user authentication," the tracer bullet might be "hardcoded user can log in and see a welcome page." No registration, no password reset, no sessions — just proof the path works.
• If a slice can't be demoed, it's probably a horizontal slice in disguise. Recut it.
• Don't create issues for "write tests" separately. Tests are part of every slice.