Write requirements prd
Skill alexe-ev/product-plugins/product-planning/skills/write-requirements-prd
Skill library for AI agents — 15 product domains, 121 skills. Tells the agent what to ask, how to reason, and what to output.
npx -y skills add alexe-ev/product-plugins --skill write-requirements-prdAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write clear, complete product requirements documents and user stories. Use this skill when a team is ready to define what needs to be built for a prioritized initiative.
SKILL.md
2.4 KB, as published. Nobody here has run it
Write Requirements & PRD
Purpose
Produce clear, structured product requirements that engineering, design, and QA can use to build and test the right thing.
Skill type
Conceptual skill
Use this skill when
- An initiative is prioritized and ready for detailed definition
- Engineering needs clear requirements before scoping or development
- A feature needs acceptance criteria defined
- A PRD review is needed for quality or completeness
Do not use this skill when
- The initiative hasn't been prioritized yet
- The goal is roadmap building (use build-roadmap-prioritization)
- The goal is sprint management or delivery coordination (use plan-delivery-collaboration)
Required inputs
- Feature or initiative description
- User segment affected
- Goal or outcome the feature serves
Optional inputs
- User stories or job stories
- Design files or mockups
- Technical constraints
- Acceptance criteria drafts
- Edge cases or exclusions
Upstream context
Works best when:
- Goal is defined
- User segment and problem are understood
- Design exploration has begun
If upstream context is missing
If the problem and user are not defined, do not write requirements. Write a problem framing first.
Downstream handoff
Output can feed:
- plan-delivery-collaboration (engineers use requirements to plan delivery)
- design-experiment-plan (if this is an A/B test, requirements feed the experiment plan)
Instructions
- Define the problem this feature solves and for whom.
- State the goal or success metric.
- Write user stories in the format: As a [user], I want to [action] so that [outcome].
- Define acceptance criteria for each user story.
- List out-of-scope items explicitly.
- Identify open questions and dependencies.
- Note edge cases and error states.
Output
Provide:
- Problem statement and goal
- User stories with acceptance criteria
- Out-of-scope definition
- Open questions
- Dependencies
- Edge cases and error states
Risks / caveats
- Do not write requirements without knowing the user and problem
- Acceptance criteria must be testable — avoid vague terms like "should feel easy"
- Out-of-scope sections prevent scope creep — do not skip them