| name | to-prd |
| description | Synthesize the current conversation into a PRD saved under docs/. Use after discussing a feature or change with the agent — no interview, just capture what has already been decided, surface open questions, and write the document. Trigger when the user says "write a PRD", "document this", "save this as a spec", or after a design discussion that needs to be captured before implementation starts. |
This skill synthesizes what has already been discussed into a PRD. Do NOT interview the user — capture and structure what you already know from the conversation and codebase.
Process
-
Explore the codebase to understand the current state of the areas touched by this feature, if you haven't already. Note the existing modules, boundaries, and naming conventions — use them throughout the document.
-
Identify the seams — the points in the codebase where this feature will connect to existing code. Prefer existing seams to new ones. The fewer seams, the better; the ideal is one. State which packages and layers are involved (packages/api, packages/db, apps/web, etc.).
-
Write the PRD using the template below. Save it to docs/[feature-name]/prd.md. Create the directory if it doesn't exist.
-
Surface open questions at the end of the document — anything unresolved, ambiguous, or requiring a product decision. Do not block writing the PRD on these; surface them so the user can address them separately.
Template
---
created_at: "YYYY-MM-DD HH:MM:SS"
last_modified_at: "YYYY-MM-DD HH:MM:SS"
---
# PRD — [Feature Name]
## Problem Statement
What problem does this solve? Describe it from the user's perspective, not the implementation's.
## Solution
What will be built? Describe it from the user's perspective.
## User Stories
A numbered list covering all aspects of the feature. Be exhaustive.
1. As a [actor], I want [capability], so that [benefit].
2. ...
## Implementation Decisions
The modules and boundaries involved. Do not include file paths or code snippets unless a specific shape (schema, type, state machine) was already decided in the conversation — if so, include only the decision-relevant parts.
- **Packages touched:** `packages/api`, `packages/db`, etc.
- **New procedures / endpoints:** ...
- **Schema changes:** ...
- **Auth / permission requirements:** ...
- **Architectural decisions already made:** ...
## Testing Decisions
- Which behavior will be tested (external-facing, not implementation details)
- Which modules will have tests
- Prior art in the codebase for similar tests
## Out of Scope
What is explicitly not included in this PRD.
## Open Questions
- [Question requiring product or technical decision]
- ...
## Rectifications
- [No rectifications yet]
Rules
- Save location: always
docs/[feature-name]/prd.md. Create docs/ at the project root if it doesn't exist.
- Frontmatter HELMET: always include
created_at and last_modified_at timestamps.
- Non-destructive updates: if the PRD already exists and you are updating it, never delete old requirements. Wrap deprecated text in slashes (e.g.
/old text/) and append to the ## Rectifications section with a date and rationale.
- Domain vocabulary: use the project's existing naming conventions — package names, entity names, service names. Do not invent new terms.
- No time estimates: do not include story points, hours, or deadlines.
