Prd Writer
Turn a founder's raw idea, voice-memo transcript, or scattered bullet points into a product requirements document with a fixed section order: problem, users, jobs-to-be-done, scope, non-goals, success metrics, open questions, and risks. Use when an idea needs to be written down in a form a cofounder, contractor, or AI coding agent can build from, and it is not yet a document.
Paste an idea, notes, or a voice-memo transcript and this skill returns a PRD in a fixed order: problem, users, jobs-to-be-done, scope, non-goals, success metrics, open questions, and risks. It separates what you said from what it inferred, never invents baseline numbers, and stays out of technical design so the document can be handed to any builder.
Install to ~/.claude/skills/prd-writer/SKILL.md
npx agentscamp add skills/prd-writerMost founder ideas live in a voice memo, a page of bullets, or a chat thread. None of those can be handed to a contractor, a cofounder, or an AI coding agent without the receiver filling the gaps with guesses. This skill turns whatever you have into a product requirements document (PRD) with a fixed section order, so every PRD reads the same way and the gaps are marked instead of hidden. It works on pasted text alone, with no repository, tools, or web access, so it runs identically on claude.ai, in Claude Code, and in Claude Cowork.
When to use this skill
- You have an idea in notes form and need a document a builder can start from.
- You are about to open an AI app builder or Claude Code and want the "what" settled before the "how".
- A cofounder or advisor asked "what exactly are we building?" and you answered in chat.
- You already ran the user-interview-synthesizer or competitor-teardown skill and want to fold the findings into a spec.
NOTE
This is a product document, not an engineering one. It says what to build, for whom, and how you will know it worked. It does not pick a stack, a database, or an architecture. For an engineering RFC grounded in an existing codebase, use the write-design-doc command after the PRD exists. In a Claude Code project, the /prd command runs this same procedure and writes the result to docs/prd.md.
Instructions
- Read everything the user provided before writing. Split it into statements the founder actually made and things you would have to infer. Do not ask questions up front. Write the full draft, marking every inference inline as
[ASSUMPTION]and every unresolved point as[OPEN]. A founder can correct a marked guess in seconds; an unmarked one ships. - Write the Problem section. One or two paragraphs: who has the problem, when it shows up, what they do about it today, and what that costs them in time, money, or risk. No solution language. If the notes jump straight to features, work backwards to the problem those features imply and mark it as an assumption.
- Write the Users section. Name the primary user (the person whose hands are on the product), any secondary user, and the buyer if different. One or two sentences of context each; no marketing personas.
- Write the Jobs-to-be-done section. Three to five statements in the form "When [situation], I want to [motivation], so I can [outcome]." Each must trace to the source material or carry an
[ASSUMPTION]tag. - Write the Scope section. A numbered list of what version one does, each item a behavior a user can observe ("a user can invite a teammate by email"), not a feature label ("team management"), and each testable by clicking through the product.
- Write the Non-goals section. What version one deliberately does not do, with a one-line reason each, including the adjacent features the founder will be tempted by. This section saves the mvp-scope-cutter skill from having to undo the PRD later.
- Write the Success metrics section. Two to four rows of metric, baseline, target, and time window. A baseline is a number the founder supplied or the literal text "unknown, measure first"; never invent one. Without founder numbers, targets are expressed as a direction.
- Write the Open questions section. Convert every
[ASSUMPTION]and[OPEN]tag into a question and name who can answer it (a customer, the founder, a lawyer, an engineer). - Write the Risks section. A table with columns Risk, Likelihood (low/medium/high), Impact (low/medium/high), and Mitigation. The first row is always the riskiest assumption: the single belief that, if wrong, means the product should not be built.
- Assemble and check. Output the PRD as Markdown with exactly these
##headings in this order: Problem, Users, Jobs-to-be-done, Scope, Non-goals, Success metrics, Open questions, Risks, in one to two pages. Re-read it once and remove any sentence that names a technology, vendor, or screen layout; those belong in the design doc.
Output
A single Markdown document with the eight fixed sections in order, a "Sources" line at the top stating what it was written from ("founder notes dated 9 Sep, one interview summary"), and inline [ASSUMPTION] tags wherever the skill filled a gap. Every tag reappears as a question in Open questions, so the founder can answer the list and re-run the skill for a clean second draft.
Example
Input: "I keep losing track of which contractors I've paid. Maybe an app where I upload invoices and it tells me what's outstanding. Small agencies would want this too."
Excerpt of the output:
## Problem
Owners of small agencies pay several contractors a month and track payments in email threads and a spreadsheet. [ASSUMPTION] They discover missed or duplicate payments only when a contractor complains.
## Success metrics
| Metric | Baseline | Target | Window |
| --- | --- | --- | --- |
| Invoices marked paid inside the product | unknown, measure first | majority of uploaded invoices | first 30 days |
## Open questions
- How many contractors does a typical target agency pay per month? (ask 5 agency owners)The other skills in this sequence, from interview notes to a scoped v1, are described in Claude skills for founders.
Related
- Claude Skills for Founders: 5 to Upload TodayFive Claude skills built for founders (PRD, MVP scope, interview synthesis, competitor teardown, investor update), how to upload them, and a prompt for each.
- Competitor TeardownBuild a structured teardown of one competitor from the pages, screenshots, and pricing text you paste in: positioning, target customer, pricing model, a feature table with evidence, and the wedge opportunities where you could win, with every unknown flagged as something to research rather than guessed. Use when sizing up a competitor before a PRD, a pitch, or a pricing decision and you want an analysis grounded only in what they publish.
- Mvp Scope CutterCut a feature list or PRD down to a ruthless version one: a keep / cut / later table with a one-line reason per row, plus the single smallest thing you could build to test the riskiest assumption. Use when first-release scope keeps growing, when an AI app builder session has produced more features than you can validate, or before you commit money or engineering time to a build.
- User Interview SynthesizerSynthesize one or many customer interview transcripts or call notes into themes with participant counts, verbatim representative quotes, jobs-to-be-done statements, contradictions between what people said and did, and the questions to ask next. Never invents, merges, or rewords a quote. Use after a batch of discovery calls when the notes are piling up and you need to know what people actually said before deciding what to build.
- PRDTurn an idea, pasted notes, or a notes file into a structured PRD and write it to docs/prd.md, or print it when there is no project.
- Write Design DocExplore the codebase and write a decision-oriented design doc / RFC for a feature or system change.
- Investor Update WriterDraft a monthly investor update from the metrics and notes you paste: a three-line TL;DR, a metrics table with month-over-month deltas computed only from the numbers you supplied, wins, misses stated with their numbers, explicit asks, and a runway note. Never fills in a figure you did not give. Use when the update is due, the raw numbers are in a spreadsheet export or a scratch doc, and you want a draft that is honest about the misses.