prd-receipts
Skill3 starsChanged 5 days agoMITView on GitHub
Turns interview notes, call transcripts, support tickets, or stakeholder requests into a PRD that keeps observations, inferences, and assumptions separate, with quotes as receipts, explicit non-goals, and success metrics. Use when the user asks for a PRD, product requirements, a feature spec, or to synthesize user or stakeholder interviews into requirements.
In this repository5 other files it gives its agents.
- ai-eval-receiptsSkill
- claim-receiptsSkill
- experiment-receiptsSkill
- metric-receiptsSkill
- plain-copySkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
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 18
Scope tightly: Write non-goals as carefully as goals.
- Distinctive: line 64
Never put an assumption in the Problem section.
- Very specific: line 65
Every requirement points to at least one evidence row, or is marked ASSUMPTION.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
PRD receipts
A good PRD lets an engineer see which requirements came from what people actually said or did, and which came from someone's guess. This skill keeps those apart.
Workflow
- Sort the raw input into three buckets before writing anything:
- Observed: what someone said (quote it) or did (describe it), with who and when.
- Inferred: a pattern across several observations. List the observations it rests on.
- Assumed: anything else, including the requester's proposed solution.
- Write the problem using only observed and inferred items. If the problem rests mostly on assumptions, say so at the top and recommend discovery before build.
- Separate requests from needs. A stakeholder asking for a feature is an observation about the request, not proof of the need behind it. Record both.
- Scope tightly. Write non-goals as carefully as goals.
- Attach metrics in the
metric-receiptsstyle: definition, decision it informs, and what it does not prove. - List open questions with the person who can answer each one.
- Strip private data. Replace customer names, addresses, and contact details with roles ("office manager", "field tech").
PRD template
# [Feature name]
**Status:** draft | **Owner:** ... | **Evidence strength:** strong | mixed | mostly assumed
## Problem
[2 to 4 sentences, observed and inferred only]
## Evidence
| Type | Receipt | Source (role, date) |
|---|---|---|
| Observed | "quote" | office manager, interview 1 |
| Inferred | pattern | from observations 1, 3, 4 |
| Assumed | belief | requester |
## Users and jobs
## Requirements
| ID | Requirement | Why (evidence row) | Priority |
## Non-goals
## Success metrics
## Risks and open questions
| Question | Who can answer | By when |Example (evidence rows, illustrative)
A fictional window-cleaning business building a quoting tool:
| Type | Receipt | Source |
| Observed | "I need a price while the customer is still on the phone." | office staff, requirements session |
| Observed | Quotes were built by hand from past jobs in the field-service system. | workflow walkthrough |
| Inferred | Speed of quoting matters more than precision to the cent. | sessions with owner and staff |
| Assumed | Customers will accept an estimate range instead of a fixed price. | not yet tested |
The assumed row becomes an open question, not a requirement.
Rules
- Never put an assumption in the Problem section.
- Every requirement points to at least one evidence row, or is marked
ASSUMPTION. - Quotes are verbatim; paraphrases are labeled as paraphrases.
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.