Write a PRD
If running interactively (human present), output "Read Write a PRD skill." to acknowledge. If running with --dangerously-skip-permissions (AFK/unattended), skip acknowledgement and proceed directly.
Pipeline position: /grill-me → /write-a-prd → /architect → /prd-to-issues → /do-work → shft
Process
Ask the user for a detailed description of the problem they want to solve. Let them be vague — your job is to extract clarity.
Explore the codebase to understand the existing architecture, conventions, data models, and relevant code paths.
Interview the user following the grill-me skill pattern — ask questions one at a time, provide recommended answers, explore the codebase when a question can be answered by code. Focus questions on the problem domain, solution approach, edge cases, and module boundaries.
Sketch modules — before writing the PRD, identify the major modules to build or modify. For each module: describe its public interface (what callers see), look for opportunities to extract deep modules (thin interface hiding large implementation), and determine the test boundary (where tests should verify behavior). Confirm module boundaries with the user.
Once you have a complete understanding of the problem and solution, use the template below to write the PRD. The PRD should be submitted as a GitHub issue.
PRD Template
# [Feature Name]
## Problem Statement
[What problem are we solving? Who has this problem? Why does it matter?]
## Solution
[High-level description of the approach]
## User Stories
1. [As a ____, I want ____ so that ____]
2. ...
## Implementation Decisions
### Modules
[For each module:]
- **Name**: [module name]
- **Interface**: [public API — what callers see and use]
- **Responsibility**: [what it does internally]
- **Test boundary**: [where tests verify behavior — unit, integration, or e2e]
- **Deep module opportunity**: [can the interface be simplified while keeping implementation rich?]
### Technical Decisions
[Key architectural choices, libraries, patterns]
### Schema Changes
[Database migrations, new tables/columns, API changes]
## Testing
[What needs to be tested and how]
## Out of Scope
[Explicitly list what this PRD does NOT cover]
## Further Notes
[Anything else relevant — edge cases, open questions, future considerations]
Handoff
After the PRD is complete, offer:
/architect — plan the implementation (vertical slices, dependency graphs, acceptance criteria)/prd-to-issues — skip straight to creating GitHub issues if the PRD is detailed enough
If context is high before the PRD is complete, follow the standard handoff protocol (@~/dotfiles/instructions/handoff.instructions.md) — persist progress to working/ and provide the pickup command.
1---2name: write-a-prd3description: Write a Product Requirements Document from a rough idea. Use when asked to 'write a PRD', 'create a PRD', 'plan a feature', or when starting a new feature that needs scoping.4---56# Write a PRD78If running interactively (human present), output "Read Write a PRD skill." to acknowledge. If running with --dangerously-skip-permissions (AFK/unattended), skip acknowledgement and proceed directly.910Pipeline position: `/grill-me` → **`/write-a-prd`** → `/architect` → `/prd-to-issues` → `/do-work` → `shft`1112## Process13141. Ask the user for a detailed description of the problem they want to solve. Let them be vague — your job is to extract clarity.15162. Explore the codebase to understand the existing architecture, conventions, data models, and relevant code paths.17183. Interview the user following the grill-me skill pattern — ask questions one at a time, provide recommended answers, explore the codebase when a question can be answered by code. Focus questions on the problem domain, solution approach, edge cases, and module boundaries.19204. Sketch modules — before writing the PRD, identify the major modules to build or modify. For each module: describe its public interface (what callers see), look for opportunities to extract deep modules (thin interface hiding large implementation), and determine the test boundary (where tests should verify behavior). Confirm module boundaries with the user.21225. Once you have a complete understanding of the problem and solution, use the template below to write the PRD. The PRD should be submitted as a GitHub issue.2324## PRD Template2526```markdown27# [Feature Name]2829## Problem Statement3031[What problem are we solving? Who has this problem? Why does it matter?]3233## Solution3435[High-level description of the approach]3637## User Stories38391. [As a ____, I want ____ so that ____]402. ...4142## Implementation Decisions4344### Modules4546[For each module:]4748- **Name**: [module name]49- **Interface**: [public API — what callers see and use]50- **Responsibility**: [what it does internally]51- **Test boundary**: [where tests verify behavior — unit, integration, or e2e]52- **Deep module opportunity**: [can the interface be simplified while keeping implementation rich?]5354### Technical Decisions5556[Key architectural choices, libraries, patterns]5758### Schema Changes5960[Database migrations, new tables/columns, API changes]6162## Testing6364[What needs to be tested and how]6566## Out of Scope6768[Explicitly list what this PRD does NOT cover]6970## Further Notes7172[Anything else relevant — edge cases, open questions, future considerations]73```7475## Handoff7677After the PRD is complete, offer:78791. `/architect` — plan the implementation (vertical slices, dependency graphs, acceptance criteria)802. `/prd-to-issues` — skip straight to creating GitHub issues if the PRD is detailed enough8182If context is high before the PRD is complete, follow the standard handoff protocol (`@~/dotfiles/instructions/handoff.instructions.md`) — persist progress to `working/` and provide the pickup command.
arndvs