mp-to-prd

---
name: mp-to-prd
description: Use when synthesising the current conversation and codebase understanding into a PRD published to the issue tracker — no fresh interview, the context you already have IS the input.
source: https://github.com/mattpocock/skills/blob/main/skills/engineering/to-prd/SKILL.md
generated: 2026-05-12T18:05:24.156Z
category: concept
audience: engineers
---

## Tutorials

- https://skillmake.xyz/v/mp-to-prd.mp4

## When to use

- Turning a finished grilling/planning conversation into a durable PRD on the issue tracker
- Publishing a feature spec ready for downstream /to-issues breakdown
- Capturing the modules you intend to build and which ones get tests, agreed with the user inline
- Recording what is explicitly out of scope so future contributors don't re-scope it

## Key concepts

### synthesize, don't interview

This skill assumes the grilling is already done. Use the conversation context and your codebase understanding to write the PRD. Do NOT start a fresh interview — the input is what you already know.

### module sketch with user check

Sketch out the major modules you'll need to build or modify, actively looking for opportunities to extract DEEP modules — small testable interface, lots of functionality behind it, rarely changing. Check with the user that these modules match expectations, and which ones they want tests for.

### domain glossary throughout

Use CONTEXT.md vocabulary throughout the PRD — module names, user-story actors, decisions — and respect ADRs in the area you're touching. The PRD is durable; drift here propagates.

### long, extensive user-story list

User stories follow 'As an <actor>, I want a <feature>, so that <benefit>.' The list should be EXTREMELY extensive — cover all aspects of the feature, not just the happy path. Numbered, in the user's voice, not the implementer's.

### no file paths or code snippets

Implementation decisions describe modules, interfaces, contracts, schemas, and architectural choices in prose. Do NOT include specific file paths or code snippets — they go stale very quickly. Exception: a prototype-derived state machine / reducer / schema / type shape can be inlined when it encodes a decision more precisely than prose, trimmed to decision-rich parts.

### test the external behavior

The Testing Decisions section explicitly states what makes a good test (external behavior, not implementation), which modules will be tested, and prior art for similar tests in the codebase. Pin this down here so /to-issues and /tdd downstream don't re-derive it.

### publish with ready-for-agent label

Publish the PRD to the project issue tracker and apply the `ready-for-agent` triage label. No additional triage step needed — the synthesis IS the triage.

## API reference

```
PRD template (use verbatim)
```

The shape of every PRD this skill produces. Each section is load-bearing — skipping one leaves a downstream gap.

```
## Problem Statement
The problem from the USER's perspective.

## Solution
The solution from the USER's perspective.

## User Stories
A LONG numbered list of "As an <actor>, I want a <feature>, so that <benefit>" — extensive, covers all aspects.

Example:
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending.

## Implementation Decisions
Modules being built/modified, their interfaces, technical clarifications, architectural decisions, schema changes, API contracts, specific interactions. Prose only — no file paths or code snippets (exception: a prototype-derived snippet that encodes a decision more precisely, trimmed to the decision-rich parts).

## Testing Decisions
What makes a good test (external behavior, not implementation), which modules will be tested, prior art in the codebase.

## Out of Scope
What is explicitly NOT covered by this PRD.

## Further Notes
Anything else.
```

```
Pre-publish checklist
```

Walk through this before pushing the PRD to the tracker. Catching gaps here is much cheaper than after.

```
- [ ] Codebase explored (or already explored in the conversation)
- [ ] Modules sketched, deep-module opportunities noted
- [ ] User confirmed module breakdown matches expectations
- [ ] User confirmed which modules get tests
- [ ] CONTEXT.md vocabulary used throughout
- [ ] No file paths or code snippets (except justified prototype-derived snippets)
- [ ] User stories are LONG and cover all aspects
- [ ] ready-for-agent label applied on publish
```

## Gotchas

- Do NOT interview the user — synthesize from the existing conversation. Re-interviewing wastes their time and signals you weren't listening.
- Look for DEEP-module opportunities during the module sketch — small interface, lots behind it, rarely changes.
- Confirm the module breakdown AND which modules get tests with the user before writing the PRD.
- Use CONTEXT.md vocabulary throughout — drift in a durable doc propagates to every downstream issue.
- User stories must be EXTENSIVE. A short list signals the spec isn't fleshed out.
- No file paths or code snippets in Implementation Decisions — they rot. Exception: prototype-derived state machines / schemas / types when prose can't encode the decision as precisely.
- Out of Scope is a load-bearing section, not a throwaway. Be explicit about what's excluded so future contributors don't re-scope it.
- Apply the `ready-for-agent` triage label on publish — no separate triage pass needed.

---
Generated by SkillMake from https://github.com/mattpocock/skills/blob/main/skills/engineering/to-prd/SKILL.md on 2026-05-12T18:05:24.156Z.
Verify against source before relying on details.

File: ~/.claude/skills/mp-to-prd/SKILL.md