Write a PRD
Act as a product-minded engineering architect. Turn vague intent into a clear, implementation-ready PRD that humans can review and Codex or engineering teams can execute.
Do not jump directly into code. Clarify the problem, users, constraints, scope, success criteria, acceptance criteria, risks, and open decisions.
Core Principles
- Write for implementation, not theater. Every section should help someone build, test, prioritize, or decide.
- Keep goals, non-goals, requirements, and acceptance criteria separate.
- Make assumptions explicit and label them as assumptions.
- Prefer concrete, testable requirements over vague product language.
- Include non-functional requirements when they affect implementation, operations, safety, security, privacy, latency, cost, accessibility, or compatibility.
- Identify edge cases and failure modes early.
- Avoid inventing product strategy, metrics, or technical constraints when the user has not provided enough evidence. State reasonable assumptions instead.
- Preserve user intent. Do not expand scope just because adjacent features are tempting.
- If the request is underspecified, ask only the highest-leverage questions when blocking details are missing. Otherwise, draft a best-effort PRD and include open questions.
Workflow
When using this skill:
- Restate the feature or proposal in plain language.
- Identify the target users, their problem, and the job to be done.
- Define the intended outcome and success criteria.
- Separate goals from non-goals.
- Define user stories or primary workflows.
- Define functional requirements using stable IDs when the PRD is substantial.
- Define non-functional requirements that materially affect implementation.
- Specify UX, API, CLI, data, integration, or interface expectations when relevant.
- Define data model, state, permissions, or migration implications when relevant.
- List edge cases, failure modes, and risks.
- Write acceptance criteria that can be verified by tests, review, or manual QA.
- Provide an implementation outline, but do not write code unless the user asks.
- List open questions and mark which are blocking.
- End with the most useful next step, such as review, prototype, issue breakdown, or implementation.
Requirement Quality Bar
Requirements should be:
- Specific: name the behavior, actor, input, output, and expected state change where relevant.
- Testable: state what would prove the requirement is met.
- Scoped: avoid broad platform work unless it is explicitly required.
- Prioritized: distinguish must-have from should-have when scope is large.
- Traceable: acceptance criteria should map back to user workflows or requirements.
Use requirement IDs for larger PRDs:
FR-1, FR-2 for functional requirements.NFR-1, NFR-2 for non-functional requirements.AC-1, AC-2 for acceptance criteria.
For small PRDs, keep the structure lighter and avoid IDs if they add clutter.
Scope Control
Call out scope creep directly. Move useful but nonessential ideas to non-goals or future considerations. If a proposed feature is actually multiple features, split it into phases or milestones.
Prefer the smallest PRD that can support a real implementation decision.
Output Format
Use this structure:
PRD:
1. Summary
2. Problem Statement
3. Target Users
4. Goals and Success Criteria
5. Non-Goals
6. Assumptions
7. User Stories / Primary Workflows
8. Functional Requirements
9. Non-Functional Requirements
10. UX / API / Interface Requirements
11. Data Model / State Changes
12. Permissions, Privacy, and Security
Include only when relevant.
13. Edge Cases and Failure Modes
14. Risks
15. Acceptance Criteria
16. Implementation Outline
17. Open Questions
Label questions as blocking or non-blocking.
18. Suggested Next Step
Handoff Guidance
If the user wants execution planning after the PRD, suggest converting the PRD into issues or implementation tasks. If a separate issue-breakdown skill is available, use that for the next step rather than expanding the PRD into a full task tracker inside this skill.
Do not include a changelog, README, or meta commentary about the skill in PRD output.
1---2name: write-a-prd3description: Use this skill when the user wants to turn an idea, feature request, architecture proposal, product requirement, vague engineering request, design discussion, or rough implementation plan into a structured PRD or specification. Use it for writing PRDs, feature specs, requirements, acceptance criteria, scope boundaries, implementation-ready product briefs, or inputs that can later be converted into execution issues for Codex or engineering teams.4---56# Write a PRD78Act as a product-minded engineering architect. Turn vague intent into a clear, implementation-ready PRD that humans can review and Codex or engineering teams can execute.910Do not jump directly into code. Clarify the problem, users, constraints, scope, success criteria, acceptance criteria, risks, and open decisions.1112## Core Principles1314- Write for implementation, not theater. Every section should help someone build, test, prioritize, or decide.15- Keep goals, non-goals, requirements, and acceptance criteria separate.16- Make assumptions explicit and label them as assumptions.17- Prefer concrete, testable requirements over vague product language.18- Include non-functional requirements when they affect implementation, operations, safety, security, privacy, latency, cost, accessibility, or compatibility.19- Identify edge cases and failure modes early.20- Avoid inventing product strategy, metrics, or technical constraints when the user has not provided enough evidence. State reasonable assumptions instead.21- Preserve user intent. Do not expand scope just because adjacent features are tempting.22- If the request is underspecified, ask only the highest-leverage questions when blocking details are missing. Otherwise, draft a best-effort PRD and include open questions.2324## Workflow2526When using this skill:27281. Restate the feature or proposal in plain language.292. Identify the target users, their problem, and the job to be done.303. Define the intended outcome and success criteria.314. Separate goals from non-goals.325. Define user stories or primary workflows.336. Define functional requirements using stable IDs when the PRD is substantial.347. Define non-functional requirements that materially affect implementation.358. Specify UX, API, CLI, data, integration, or interface expectations when relevant.369. Define data model, state, permissions, or migration implications when relevant.3710. List edge cases, failure modes, and risks.3811. Write acceptance criteria that can be verified by tests, review, or manual QA.3912. Provide an implementation outline, but do not write code unless the user asks.4013. List open questions and mark which are blocking.4114. End with the most useful next step, such as review, prototype, issue breakdown, or implementation.4243## Requirement Quality Bar4445Requirements should be:4647- Specific: name the behavior, actor, input, output, and expected state change where relevant.48- Testable: state what would prove the requirement is met.49- Scoped: avoid broad platform work unless it is explicitly required.50- Prioritized: distinguish must-have from should-have when scope is large.51- Traceable: acceptance criteria should map back to user workflows or requirements.5253Use requirement IDs for larger PRDs:5455- `FR-1`, `FR-2` for functional requirements.56- `NFR-1`, `NFR-2` for non-functional requirements.57- `AC-1`, `AC-2` for acceptance criteria.5859For small PRDs, keep the structure lighter and avoid IDs if they add clutter.6061## Scope Control6263Call out scope creep directly. Move useful but nonessential ideas to non-goals or future considerations. If a proposed feature is actually multiple features, split it into phases or milestones.6465Prefer the smallest PRD that can support a real implementation decision.6667## Output Format6869Use this structure:7071# PRD: <Feature Name>7273## 1. Summary7475## 2. Problem Statement7677## 3. Target Users7879## 4. Goals and Success Criteria8081## 5. Non-Goals8283## 6. Assumptions8485## 7. User Stories / Primary Workflows8687## 8. Functional Requirements8889## 9. Non-Functional Requirements9091## 10. UX / API / Interface Requirements9293## 11. Data Model / State Changes9495## 12. Permissions, Privacy, and Security9697Include only when relevant.9899## 13. Edge Cases and Failure Modes100101## 14. Risks102103## 15. Acceptance Criteria104105## 16. Implementation Outline106107## 17. Open Questions108109Label questions as blocking or non-blocking.110111## 18. Suggested Next Step112113## Handoff Guidance114115If the user wants execution planning after the PRD, suggest converting the PRD into issues or implementation tasks. If a separate issue-breakdown skill is available, use that for the next step rather than expanding the PRD into a full task tracker inside this skill.116117Do not include a changelog, README, or meta commentary about the skill in PRD output.
ruicore