agentleFS
Sign inStart free
Tngc93Tngc93/product-management-skills/skills/write-prd/SKILL.md

write-prd

Skill0 starsChanged 31 days agoMITView on GitHub

Turn rough input (meeting notes, a Slack thread, a feature idea, customer feedback, a half-written doc) into a one-page product requirements document with a problem statement, users, measurable success metrics, non-goals, requirements and open questions. Use when the user asks for a PRD, a spec, a one-pager, a product brief or "write this up properly".

28 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use write-docs, cut-release and 7 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.
  • SentrySkill

    write-docs

    Create or update documentation pages for the Abacus docs site. Use when adding new documentation, updating existing pages, or ensuring docs stay in sync with code changes. Ensures pages follow Starlight patterns and build correctly.

    Also in 3 projects that use this

  • MicrosoftSkill

    cut-release

    Use this skill to cut an APM release from the current worktree: assess whether the cycle since the last tag warrants a patch or minor bump (semver discipline against the merged-since-last-tag diff), sanitize the [Unreleased] CHANGELOG block into a dated version block with one concise "so what" entry per merged PR (drop internal-only churn, consolidate duplicates), bump pyproject.toml + uv.lock, run the CI-mirror lint chain, and open the release PR. Activate on "ship a release", "cut v0.x", "release prep", "bump and PR", "open release PR", "what kind of release do we need", or any phrasing that ends in opening a release PR -- even when the user does not say "skill". Stops BEFORE tagging; tagging stays a human gate that triggers the release workflow. Refuses to bump to a major (>= 1.0.0) version without explicit operator confirmation.

    Also in 3 projects that use this

  • SentrySkill

    write-tests

    Write tests following project conventions. Use when adding new tests or modifying existing ones.

    Also in 3 projects that use this

  • VercelSkill

    agent-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

  • GoogleSkill

    tdd

    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

  • GoogleSkill

    grill-me

    A relentless interview to sharpen a plan or design.

    Also in 4 projects that use this

  • +1 more from getsentry
  • +1 more from google

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 24 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If ${CLAUDE_PLUGIN_ROOT} was not substituted (for example in Codex), the CLI is at ../../cli/pm-skills.mjs relative to this file.

    line 16
  2. Distinctive:

    Read everything the user gave you.

    line 20
  3. Very specific:

    If the user cannot answer, write the PRD anyway and put each gap in Open questions with a name next to it.

    line 27
  4. Very specific:

    Start from the template: pm-skills template write-prd.

    line 31
  5. Distinctive:

    Write in the language the user writes in.

    line 39

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Write a PRD

A PRD exists so that people who were not in the room build the right thing and know when it worked. Optimise for that reader. One page is the goal, two is the limit.

The CLI used below runs with Node 18.17+:

node "${CLAUDE_PLUGIN_ROOT}/cli/pm-skills.mjs" <command>

If ${CLAUDE_PLUGIN_ROOT} was not substituted (for example in Codex), the CLI is at ../../cli/pm-skills.mjs relative to this file. Below, pm-skills means that command.

1. Collect the input

Read everything the user gave you. Before writing, you need four things. If the input does not contain them, ask for the missing ones in one message, at most three questions:

  1. The problem, in the user's or customer's words, and evidence that it is real (data, tickets, quotes, lost deals).
  2. Who has it, and roughly how many of them.
  3. What success looks like: the metric that should move, its current value, and by when.
  4. Constraints: deadline, budget, platforms, legal, dependencies.

If the user cannot answer, write the PRD anyway and put each gap in Open questions with a name next to it. Never invent numbers. A metric with an unknown baseline is written as baseline: unknown, measure in week 1.

2. Write it

Start from the template: pm-skills template write-prd. Rules:

  • Problem before solution. The problem section must make sense even if the proposed solution is thrown away.
  • Metrics are numbers with a baseline and a date: checkout conversion on mobile 2.1% → 2.5% by 30 Nov. Include one guardrail metric that must not get worse.
  • Non-goals are decisions, not a dumping ground. Each one saves a future argument.
  • Requirements are observable behaviour, numbered so they can be referenced (R1, R2…). Mark each Must or Should. If everything is Must, nothing is.
  • No vague words. "Fast", "easy", "seamless", "intuitive", "improve" are replaced by what they mean in this case.
  • Open questions have an owner and a date, or they are not questions, they are hopes.
  • Write in the language the user writes in. Keep product and technical terms as the team uses them.

3. Check it

Run pm-skills lint <file> --type prd. Fix every error. For each warning, either fix it or leave it on purpose and be ready to say why. Then re-read the document as an engineer who must estimate it, and as an executive who must fund it. Cut anything neither of them needs.

4. Hand it over

Give the user the document and, in two or three lines, the decisions you made on their behalf and the open questions that block work. If they want stories next, the slice-stories skill takes it from here.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free