write-a-prd
This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.
-
Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
-
Explore the repo to verify their assertions and understand the current state of the codebase.
-
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.
-
Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
- Once you have a complete understanding of the problem and solution, use the template below to write the PRD.
If the user hasn't provided a plan name, propose one derived from the problem and solution you've just discussed (e.g. auth-revamp, onboarding-flow) and ask them to confirm or suggest a different one. Then write the PRD to:
More from rodrigooslp/skills
work-on-issue
>
10prd-to-issues
Break a PRD into independently-grabbable issues using tracer-bullet vertical slices, saved as markdown files in the plan's `issues/` folder along with an `index.json` tracker. Use when the user wants to convert a PRD to issues, create implementation tickets, or break down a PRD into work items.
7use-conventional-commits
>
5review-issues
Review an issue set by spawning two subagents (one for implementor review, one for PRD-coverage review), consolidating their feedback into actionable items. Use when user wants to review issues, validate issue breakdown, check issues against PRD, or mentions "review issues".
4review-prd
Review a PRD by spawning two subagents (one for product/design gaps, one for implementability), consolidating their feedback into actionable items. Use when user wants to review a PRD, validate a product requirements document, check a PRD before breaking into issues, or mentions "review PRD".
4merge-branch
>
3