theneoai To PRD
One-Liner
Synthesize what has already been discussed into a structured Product Requirements Document — without interviewing the user again.
§ 1 · Core Constraint
Do NOT interview the user. This skill runs after a design conversation has already happened. Its job is to organize and commit that knowledge — not to gather more. If key information is missing, note the gap in the PRD's "Open Questions" section rather than pausing to ask.
§ 2 · Workflow
Step 1 — Codebase Exploration
Before writing anything:
- Read
CONTEXT.mdif present — use its canonical terms throughout the PRD - Read relevant ADRs — the PRD must not contradict past decisions without noting it
- Identify the major modules the feature will touch or create
- Note any existing patterns the new code should follow (naming, error handling, testing)
Step 2 — Module Sketch
Before drafting the PRD body, sketch the major modules:
- What new modules will be created?
- What existing modules will be modified?
- Prefer deep modules: encapsulate significant behavior behind a simple, testable interface
This sketch goes into the PRD's Implementation Decisions section.
Step 3 — Write the PRD
Use this template:
PRD: [Feature Name]
Problem Statement [One paragraph: what user problem does this solve? What is the cost of not building it?]
Solution [One paragraph: what does the feature do at a high level?]
User Stories
- As a [role], I want to [action] so that [benefit]
- ...
Implementation Decisions
- Module:
<name>— owns [behavior]; interface: [description] - Module:
<name>— modified to [change]; seam used: [description]
Testing Decisions
- [Behavior to test]: [test type and approach]
- [Edge case]: [how it will be covered]
Out of Scope
- [Explicitly excluded functionality]
Open Questions
- [Anything that needs a human decision before implementation starts]
Further Notes
- [Performance considerations, security notes, rollout strategy, etc.]
Important: Do not include specific file paths or implementation code in the PRD. File paths rot rapidly; behavior descriptions survive. Implementation will determine exact paths.
Step 4 — Publish
Post the PRD to the project issue tracker with:
- Label:
needs-triage(so the issue enters the triage workflow) - Title format:
feat: [feature name] - Link back to the conversation or design session if available
§ 3 · PRD Quality Checklist
| Check | Pass Condition |
|---|---|
| Uses canonical terms | All entity/action names match CONTEXT.md |
| No file paths | Implementation details left to implementation phase |
| Explicit out-of-scope | At least one item listed |
| Module sketch present | Major modules identified and their interfaces described |
| Open questions captured | Missing info noted, not blocking the PRD |
| Testable user stories | Each story has an implied acceptance test |
§ 4 · When to Use This Skill
Use when:
- A feature has been fully or mostly designed in conversation
- Preparing for a sprint and need to create issues
- An enhancement issue was promoted from
issue-triagetoready-for-humanand needs a full spec
Do NOT use when:
- The feature has not been discussed at all (nothing to synthesize)
- The goal is just a small bug fix (overkill — use
debug-diagnose)
§ 5 · Relationship to Other Skills
| Skill | When to reach for it |
|---|---|
zoom-out |
Run first to map what modules the feature will touch |
issue-triage |
After publishing — triage the created issue |
tdd-workflow |
When implementation begins — start from the user stories as behaviors |
architecture-review |
If the PRD reveals a need for significant structural changes |