SPEC WRITINGTEMPLATE
Product Requirements Document
The PRD is the one-page answer to "what are we building and why," written before any code exists and read by every session after. Fill it in badly and your agent will happily build the wrong thing at full speed. Fill it in honestly, including the non-goals, and most of the clarifying questions disappear before they get asked.
The AFD considerations section is not decorative. Fill it in or rethink the project, but do not delete the section.
markdown
# [Project Name] PRD
## Summary
One paragraph: what is this, who is it for, what problem does it solve,
what does success look like.
## Goals
- Goal 1 (the primary outcome you want).
- Goal 2.
- Goal 3.
## Non-goals
- Thing 1 (something you might be tempted to build that you're
explicitly NOT building in this scope).
- Thing 2.
- Thing 3.
## Users
- USER TYPE 1 (e.g., "office staff at a roofing company"). Their
context, their needs, their constraints.
- USER TYPE 2.
## Success Metrics
- Metric 1 (how you'll know the project succeeded, e.g., "office
staff process incoming leads in <2 minutes vs. current 8 minutes").
- Metric 2.
## Functional Requirements
(Bulleted list, each requirement in user-language. 10-30 items
typical for a small project.)
- F1: [Requirement description.]
- F2: ...
- F3: ...
## Non-Functional Requirements
- Performance: [e.g., "Pages load in under 2s on 4G."]
- Reliability: [e.g., "99% uptime during business hours."]
- Security: [e.g., "PCI compliance for payment handling."]
- Privacy: [e.g., "Customer data never leaves the country."]
## Constraints
- Tech: [e.g., "Must run on a Mac mini we already own."]
- Budget: [e.g., "Recurring costs under $50/month."]
- Timeline: [e.g., "MVP in 4 weeks."]
- Dependencies: [e.g., "Integrates with Stripe for payments."]
## Out of Scope
(Things explicitly not being built now. Prevents scope creep and
agent overreach.)
- O1: ...
- O2: ...
## AFD (Actually Fucking Dangerous) Considerations
(See §1.4. If any of these apply, the section below describes how
the project will handle them. If none apply, write "None.")
- Does this software touch health, medical, dosing, or treatment
decisions?
- Does this software handle authentication, authorization, or
access control for sensitive data?
- Does this software touch children's data, seniors' data, or
any vulnerable population's data?
- Does this software control a physical device a human depends on?
- Could a wrong answer from this software cause real-world harm
to someone who isn't the developer?
If any answer is yes: identify the senior developer or licensed
professional who will review the AFD-adjacent code before it ships.
Write their name here: ____________
## Open Questions
(Things you don't know yet. Resolve before building.)
- Q1: ...
- Q2: ...