prd-writer
Skill4 starsChanged 27 days agoMITView on GitHub
Use when writing a PRD, product requirements document, feature spec, product brief or requirements doc, turning a feature idea into requirements, or reviewing an existing PRD for gaps.
35 other projects use a version of this.
Adopted by
Most recently taken up by
- alunadev/ald-skillstheir own version, first seen Nov 8, 2026
- shawnclybor/clybor-claude-toolingtheir own version, first seen Nov 8, 2026
- Sach1ng/PM-operating-OStheir own version, first seen Nov 1, 2026
- awahids/noskilltheir own version, first seen Oct 15, 2026
- sankar2code/Claude-Skill_SubAgent-Builder-Collectionstheir own version, first seen Oct 13, 2026
- Arzeroe/Claude-skillstheir own version, first seen Oct 13, 2026
Used with
Projects with it also use experiment-designer, user-research and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Dokkabei97Skillexperiment-designer
Designs A/B tests and product experiments with hypothesis structuring, sample size calculation, duration estimation, and result interpretation. Unified framework for both product and marketing experiments.
Also in 3 projects that use this
AnthropicSkilluser-research
Plan, conduct, and synthesize user research. Trigger with "user research plan", "interview guide", "usability test", "survey design", "research questions", or when the user needs help with any aspect of understanding their users through research.
Also in 3 projects that use this
OpenAISkillbrainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Also in 3 projects that use this
Other versions35 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 35
- aakashg/pm-claude-code-setup★ 152same name
- cigery-useio/useio-skills★ 103same name
- skinnerlee1225/enterprise-prd-toolkit★ 45same name
- nimbalyst/skills★ 28same name
- vibepm666/prd-writer★ 27same name
- aroyburman-codes/pm-skills★ 25same name
- HiWhaleW/skill★ 22same name
- Panix22/prd-writer-skill★ 19same name
- samlaying/pm-skills★ 9same name
- v60samurai/builder-os★ 8same name
25 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- accessibility-auditSkill
- api-design-reviewSkill
- api-test-writerSkill
- architecture-diagramSkill
- bug-debuggerSkill
- bug-report-writerSkill
- changelog-writerSkill
- codebase-onboardingSkill
- code-reviewSkill
- database-schema-designSkill
- dependency-upgradeSkill
- design-handoff-specSkill
- design-reviewSkill
- dockerize-appSkill
- figma-design-compareSkill
- flaky-test-fixerSkill
- git-commit-writerSkill
- github-actions-ciSkill
- playwright-e2e-testsSkill
- proof-of-done-liteSkill
- readme-writerSkill
- refactor-plannerSkill
- security-auditSkill
- seo-auditSkill
- test-case-generatorSkill
- test-plan-writerSkill
- test-writerSkill
- ux-research-synthesisSkill
- ux-writingSkill
- web-performance-auditSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 4 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 25 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Ask only blocking questions: If an unknown would change the scope, ask.
- Very specific: line 36
Never present invented numbers as facts.
- Distinctive: line 37
Keep design and implementation details out unless they are hard constraints.
- Distinctive: line 38
Prefer one page of precise text over five pages of generic sections.
- Distinctive: line 39
When reviewing an existing PRD, list the gaps against the quality bar, most important first, then offer the revised sections.
“Common” is measured: kept by at least 6 in 10 of the 25 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PRD Writer
Overview
A PRD makes a team agree on the problem, the definition of success, and the scope before anyone designs or builds. Separate evidence from assumptions, make every goal measurable, and make every requirement testable.
Method
- Gather context: the request, any notes or data the user provides, the existing product (read the code or docs if available), constraints and deadlines.
- State the problem before the solution: who has the problem, how often, what it costs them and the business, and the evidence.
- Ask only blocking questions. If an unknown would change the scope, ask. Otherwise record it under Open questions and keep going.
- Write using template.md.
- Self-check against the quality bar below before handing it over.
Quality bar
| Section | Must have |
| Problem | Evidence (data, quotes, tickets) with source; anything unsupported is labelled Assumption: |
| Goals | Metric + current baseline + target + time frame ("checkout conversion 2.1% → 2.6% within 60 days of launch") |
| Non-goals | Explicitly excluded scope that someone might expect |
| Users | Primary and secondary personas with the job they are trying to do |
| Requirements | User stories with priority (Must, Should, Could) and acceptance criteria in Given / When / Then |
| Edge cases | Empty, error, permission, limits, concurrency, offline or slow network, migration of existing data |
| Dependencies and risks | Teams, services, legal or privacy concerns, each risk with a mitigation |
| Rollout | Phases or flags, who gets it first, how success is measured, rollback trigger |
| Open questions | Each with an owner and a decision deadline |
Rules
- Never present invented numbers as facts. Use the user's data, or write
Assumption:and say how to validate it. - Keep design and implementation details out unless they are hard constraints.
- Prefer one page of precise text over five pages of generic sections.
- When reviewing an existing PRD, list the gaps against the quality bar, most important first, then offer the revised sections.
Common mistakes
- Solution-first: "Build a saved-carts page" with no statement of the user problem.
- Vague goals: "improve engagement".
- Acceptance criteria that cannot fail ("works well on mobile").
- Missing non-goals, which lets scope grow silently.
- Treating open questions as decided.
Made by Wageesha Tripathi · LinkedIn · Email · More skills
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.