write-prd
Skill0 starsChanged 16 days agoMITView on GitHub
Write a product requirements document — problem, audience, goals, non-goals, and testable success. Use when the user asks for a PRD, product spec, requirements of what to build, or /write-prd. Do not write product code. Do not PRD a one-line bug.
28 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- adhamhaithameid/write-skillstheir own version, first seen Nov 8, 2026
- allanbian1017/skillstheir own version, first seen Nov 1, 2026
- arthjean/skillstheir own version, first seen Nov 1, 2026
- rpraharaj/ai-engineeredited, first seen Nov 1, 2026
- tam159/next-roletheir own version, first seen Nov 1, 2026
- kdy1/kdy1-scriptstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use stakeholder-update, prioritize and 5 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.
AnthropicSkillstakeholder-update
Generate a stakeholder update tailored to audience and cadence. Use when writing a weekly or monthly status for leadership, announcing a launch, escalating a risk or blocker, or translating the same progress into exec-brief, engineering-detail, or customer-facing versions.
Also in 3 projects that use this
blueOctopusAISkillprioritize
Also in 3 projects that use this
VercelSkillagent-browser
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
Also in 3 projects that use this
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 4 projects that use this
GoogleSkillgrill-me
A relentless interview to sharpen a plan or design.
Also in 4 projects that use this
BlockSkillfrontend-design
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
Also in 3 projects that use this
- +1 more from google
Other versions28 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- rpraharaj/ai-engineer★ 129% same
Wrote their own version · 27
- digoal/blog★ 8.6ksame name
- classroomio/classroomio★ 1.7ksame name
- andreaskelm/pm-brain★ 235same name
- konglong87/superPM★ 84same name
- tam159/next-role★ 67same name
- digoal/skills★ 39same name
- kdy1/kdy1-scripts★ 33same name
- Code-Shock/claude-skills★ 5same name
- RizwanZafaris/product-manager-OS★ 4same name
- arthjean/skills★ 3same name
17 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 repository66 other files it gives its agents.
- AGENTS.mdAGENTS.md
- a11y-passSkill
- assess-changeSkill
- build-regression-packSkill
- charter-exploratorySkill
- classify-dataSkill
- commitSkill
- cut-releaseSkill
- data-changeSkill
- debugSkill
- design-experimentSkill
- diff-environmentsSkill
- draft-steercoSkill
- engineering-barSkill
- explain-codeSkill
- explore-codebaseSkill
- fix-ciSkill
- handoffSkill
- implement-changeSkill
- incident-triageSkill
- lean-reviewSkill
- map-dependenciesSkill
- map-design-handoffSkill
- map-processSkill
- open-prSkill
- performanceSkill
- plan-data-migrationSkill
- plan-incrementSkill
- plan-rollbackSkill
- plan-uatSkill
- prioritize-backlogSkill
- production-passSkill
- ready-to-mergeSkill
- record-decisionSkill
- refactor-safelySkill
- revert-changeSkill
- review-architectureSkill
- review-changeSkill
- review-pipelineSkill
- security-passSkill
- shape-workSkill
- ship-notesSkill
- spec-analyticsSkill
- spec-observabilitySkill
- start-projectSkill
- synthesize-discoverySkill
- triage-blockersSkill
- triage-defectSkill
- update-raidSkill
- verify-uiSkill
- write-api-examplesSkill
- write-architectureSkill
- write-designSkill
- write-dev-tasksSkill
- write-docsSkill
- write-integration-contractSkill
- write-nfrSkill
- write-opportunitySkill
- write-requirementsSkill
- write-runbookSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 24 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Do not implement. Do not invent users, metrics, or legal constraints.
- Very specific: line 32
If the ask is already tiny (one behavior, success is obvious), say so and offer shape-work.
- Distinctive: line 47
Read AGENTS.md if present.
- Distinctive: line 52
Must / Should / Later — do not dump a wishlist into Must.
- Distinctive: line 53
No secrets. Unknowns stay unknown.
- Very specific: line 54
Leave status draft or review until the authorized human signs problem and success.
“Common” is measured: kept by at least 6 in 10 of the 24 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
Write PRD
Capture what to build and why. This is not write-design, not write-architecture, and not shape-work.
Do not implement. Do not invent users, metrics, or legal constraints.
Is this the right skill?
| Signal | Do this instead |
| One-line bug or tiny change | shape-work or implement-change |
| How we will build an agreed product | write-design |
| System boundaries | write-architecture |
| Testable functional contract | write-requirements |
| Tickets from an existing PRD | write-dev-tasks |
| Pitch / problem not yet a PRD | write-opportunity |
If the ask is already tiny (one behavior, success is obvious), say so and offer shape-work.
Required inputs
- A problem the user can point at, or an accepted opportunity brief
AGENTS.md;context/glossary.mdif present
Human decisions (do not invent)
- Who it is for, if not in context
- Success numbers that are not already measured
- Must vs later
Procedure
- Read
AGENTS.mdif present. Skim the product enough to avoid inventing a second app. - Find the home: first existing
docs/prd/,docs/product/, a pathAGENTS.mdnames, or offer to createdocs/prd/. - Name:
docs/prd/YYYY-MM-DD-<slug>.md. - Open references/prd-template.md. Copy every heading. Write
n/awhen unused. - Problem is a hurt, not a solution. Non-goals is non-empty. Success checks are yes/no and at least one fails today. Do not invent a baseline.
- Must / Should / Later — do not dump a wishlist into Must. Journeys cover happy, empty, and error when user-facing.
- No secrets. Unknowns stay unknown.
- Leave status
draftorreviewuntil the authorized human signs problem and success. Record source revision and approval evidence using the home incontext/decision-rights.md; an agent must not promote its own draft to accepted. If scope or success changes, invalidate affected downstream approval and verification.
Output
- Path:
docs/prd/YYYY-MM-DD-<slug>.md - Template:
references/prd-template.md
Quality bar
- A stranger can tell shipped vs not from Success
- Non-goals is non-empty
- Requirements do not specify tables, frameworks, or folder layout
- Unused headings are
n/a - Next names a real skill
- Accepted status is backed by human approval evidence for this revision
Done
- Path or the full text in the reply
- The problem in one sentence
- Next skill:
write-requirements,write-architecture,write-design, orshape-work
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.

