write-a-prd
This skill will be invoked when the user wants to create a PRD.
-
Ask the user for a concise but clear description of the problem they want to solve, the outcome they want, who it is for, and any initial ideas for solutions.
-
Reuse the discussion already present in the current thread.
If the problem, constraints, and key decisions have already been clarified earlier in the conversation, do not repeat the same interview. Only ask follow-up questions for unresolved, ambiguous, or conflicting points.
- Explore the repo to verify their assertions and understand the current state of the codebase when relevant.
Use repo findings to answer factual questions yourself instead of asking the user unnecessarily. Call out existing behavior, terminology, and constraints that materially affect the PRD.
- Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Make sure the discussion covers the complete feature surface, including:
- primary actors and goals
- core workflows
- permissions and roles
- edge cases and failure modes
- integrations and external dependencies
- rollout or migration constraints
- explicit out-of-scope items
- Once you have a complete understanding of the problem and solution, use the template below to write the PRD.
The PRD should stay focused on business value, user-facing behavior, scope, constraints, and open questions. Do not turn it into an implementation spec.
The user stories must be exhaustive but not repetitive. They should cover the full surface area of the feature, including normal flows, edge cases, permissions, failure and recovery flows, and lifecycle actions when relevant.
- Show the draft PRD to the user and revise it until they approve it.
Do not submit the PRD as a GitHub issue until the user explicitly approves the final draft.
- Once the user approves the draft, submit the PRD as a GitHub issue.
Problem Statement
The problem that the user is facing, from the user's perspective.
Goals
A concise list of the primary outcomes this feature should achieve.
Solution
The solution to the problem, from the user's perspective.
User Stories
A LONG, numbered list of user stories. Each user story should be in the format of:
- As an
<actor>, I want a<feature>, so that<benefit>
This list of user stories should be exhaustive but not repetitive. It should cover all important aspects of the feature, including primary flows, edge cases, permissions and roles, failure and recovery flows, and lifecycle actions when relevant.
Scope
A description of what is included in this PRD.
Constraints
Business, product, platform, compliance, integration, or rollout constraints that affect the feature.
Engineering Notes
Only include product-relevant technical constraints or commitments that materially affect scope or feasibility.
Do NOT include implementation plans, module breakdowns, file paths, code snippets, API shapes, schema details, or test strategy by default.
Out of Scope
A description of the things that are out of scope for this PRD.
Open Questions
Any unresolved questions that remain after discussion.
Further Notes
Any further notes about the feature.
More from sones3/skills
prd-to-issues
Break a PRD into independent GitHub issues, with backend-first then frontend-linked workflow. Each issue is fully discussed before implementation. Use when converting a PRD to actionable work items.
13grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
12ubiquitous-language
Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD".
11start-next-issue
Suggests the next GitHub issue to work on from a PRD breakdown, confirms it with the user, and initiates the pre-implementation discussion.
10discuss-in-french
Ensures that discussions with the user are conducted in French, but all deliverables, documentation, and implementation outputs are written in English.
10github-triage
Triage GitHub issues through a label-based state machine. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
1