| name | to-prd |
| description | Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context. |
This skill helps you convert the current conversation context and codebase status into a structured Product Requirement Document (PRD).
[!IMPORTANT]
Do not interview the user. Instead, synthesize what you already know from the conversation history and codebase.
📋 Steps to Follow
1. Research and Explore
- Explore the repository to understand the current state of the codebase.
- Use the project's domain glossary terms throughout the PRD.
- Follow and respect any Architecture Decision Records (ADRs) in the codebase areas you are modifying.
2. Design the Architecture
- Plan the major modules to build or modify.
- Design deep modules (modules that hide complex details behind simple, stable, and testable interfaces) that can be tested in isolation.
- Align with the user on:
- Whether the proposed modules match their expectations.
- Which modules require tests.
3. Write the PRD
Draft the PRD using the template structure below.
📄 PRD Template
Use the following sections to write the PRD:
🔍 Problem Statement
Explain the problem from the user's perspective. What pain point does this address?
💡 Solution
Describe the solution and how it resolves the problem from the user's perspective.
👥 User Stories
Provide a detailed, numbered list of user stories. Cover all aspects of the feature.
Format:
[Number]. As an [actor], I want [feature], so that [benefit].
Example: 1. As a bank customer, I want to see my account balances, so that I can make informed spending decisions.
🛠️ Implementation Decisions
List the technical decisions for the solution:
- Modules to be built or modified.
- Interfaces/APIs for those modules.
- Schema or database changes.
- Technical/architectural clarifications and interactions.
[!WARNING]
Do not include specific file paths or code snippets (they get outdated quickly).
Exception: You may inline a code snippet if it is a prototype that explains a decision (like a state machine, schema, or type shape) better than text. Keep it brief and mention it is from a prototype.
🧪 Testing Decisions
List the testing strategies:
- What makes a good test (focus on testing external behavior, not implementation details).
- Which modules will be tested.
- Existing tests in the codebase to use as a reference (prior art).
🚫 Out of Scope
Clearly list features or tasks that will not be covered by this PRD.
📝 Further Notes
Add any other relevant details or notes.
