Create PRD
Overview
Generate a problem-first Product Requirements Document with measurable success metrics, testable acceptance criteria, and clearly scoped boundaries. Every PRD starts from the user problem, not the solution.
Workflow
Read product context — Scan .chalk/docs/product/ for the product profile (0_product_profile.md), JTBD docs, existing PRDs, and user research. Also check .chalk/docs/engineering/ for architecture docs that inform feasibility. If no product context exists, note that explicitly and work from what the user provides.
Accept the feature request — Parse $ARGUMENTS to identify the problem space, target user, and any constraints the user has mentioned. If $ARGUMENTS is vague (e.g., "notifications"), ask one round of clarifying questions before proceeding. Never silently assume the scope.
Determine the next file number — Read filenames in .chalk/docs/product/ to find the highest numbered file. The next PRD number is highest + 1.
Generate the PRD — Write all sections listed below. Every section is mandatory. Do not leave sections empty or write "TBD" without also adding the item to Open Questions.
Cross-reference architecture — Read .chalk/docs/engineering/ to validate that the proposed solution is feasible within the current stack. Flag any new infrastructure, services, or third-party dependencies in the Dependencies section.
Flag assumptions — Any statement that is not grounded in an existing doc or explicit user input goes into Open Questions. Be aggressive about surfacing unknowns.
Write the file — Save to .chalk/docs/product/<n>_prd_<slug>.md.
Confirm — Tell the user the PRD was created, share the file path, and highlight the top 2-3 open questions that need resolution before engineering work begins.
PRD Structure
# PRD: <Feature Name>
Last updated: <YYYY-MM-DD> (Initial draft)
## Problem Statement
What user problem are we solving and why does it matter now? Link to a Job-to-be-Done if one exists in the product docs. State the problem from the user's perspective, not the system's.
## Target Users
Who specifically experiences this problem? Use personas from product docs if available. Include:
- Primary persona and their context
- Secondary personas (if any)
- Who this is NOT for (anti-personas)
## Success Metrics
How will we know this worked? Every metric must be:
- Measurable (has a number or clear threshold)
- Time-bound (measured over what period)
- Baselined (current state vs. target state)
| Metric | Current | Target | Timeframe |
|--------|---------|--------|-----------|
| ... | ... | ... | ... |
## User Stories
Group by user activity. Each story follows:
**Activity: <activity name>**
As a [persona], I want [action], so that [outcome].
Acceptance Criteria:
- Given [context], when [action], then [expected result]
- Given [context], when [action], then [expected result]
## Acceptance Criteria (Feature-Level)
Testable conditions that must ALL be true for the feature to be considered complete. Write in Given/When/Then format. These are the contract between product and engineering.
## Edge Cases
Enumerate scenarios that are easy to overlook:
- Error states (network failure, invalid input, timeout)
- Empty states (first-time user, no data)
- Boundary conditions (max limits, concurrent users, large payloads)
- Permission boundaries (unauthorized access, expired sessions)
- Backwards compatibility (existing users, data migration)
## Out of Scope
Explicitly list what this PRD does NOT cover. This section prevents scope creep and misaligned expectations. Be specific: "Real-time sync is out of scope" not "Some features are out of scope."
## Dependencies
- **Internal**: Other teams, services, or features that must exist first
- **External**: Third-party APIs, vendor contracts, compliance requirements
- **Technical**: Infrastructure, tooling, or architectural changes required
## Open Questions
Numbered list of unresolved items that block confident implementation. Each question should name who can answer it.
1. [Question] — Owner: [person/team]
Output
- File:
.chalk/docs/product/<n>_prd_<slug>.md
- Format: Plain markdown, no YAML frontmatter
- First line:
# PRD: <Feature Name>
- Second line:
Last updated: <YYYY-MM-DD> (Initial draft)
Anti-patterns
- Solution-first writing — Never start with "We will build X." Start with the user problem. If the user gives you a solution ("add a button that..."), dig back to the underlying need.
- PRDs without success metrics — A PRD with no measurable outcomes is a wish list. Every PRD needs at least 2 metrics with concrete targets.
- Missing out-of-scope section — Omitting this guarantees scope creep. Even if the scope seems obvious, write it down.
- Vague acceptance criteria — "The feature should work well" is not testable. Every criterion must follow Given/When/Then and be verifiable by QA without asking the PM what "well" means.
- Feature lists instead of user outcomes — "Add filtering, sorting, and pagination" describes implementation, not value. Write "Users can find the specific record they need within 10 seconds" instead.
- Copy-pasting the template with blanks — Every section must contain substantive content. If you genuinely don't have information for a section, move the gap to Open Questions and explain what's missing.
- Ignoring existing product context — Always check
.chalk/docs/product/ first. PRDs that contradict the product profile or duplicate existing PRDs waste everyone's time.
1---2name: create-prd-63description: Create a structured Product Requirements Document when the user asks to write a PRD, define requirements, or spec out a feature4---5
6# Create PRD
7
8## Overview
9
10Generate a problem-first Product Requirements Document with measurable success metrics, testable acceptance criteria, and clearly scoped boundaries. Every PRD starts from the user problem, not the solution.
11
12## Workflow
13
141. **Read product context** — Scan `.chalk/docs/product/` for the product profile (`0_product_profile.md`), JTBD docs, existing PRDs, and user research. Also check `.chalk/docs/engineering/` for architecture docs that inform feasibility. If no product context exists, note that explicitly and work from what the user provides.
15
162. **Accept the feature request** — Parse `$ARGUMENTS` to identify the problem space, target user, and any constraints the user has mentioned. If `$ARGUMENTS` is vague (e.g., "notifications"), ask one round of clarifying questions before proceeding. Never silently assume the scope.
17
183. **Determine the next file number** — Read filenames in `.chalk/docs/product/` to find the highest numbered file. The next PRD number is `highest + 1`.
19
204. **Generate the PRD** — Write all sections listed below. Every section is mandatory. Do not leave sections empty or write "TBD" without also adding the item to Open Questions.
21
225. **Cross-reference architecture** — Read `.chalk/docs/engineering/` to validate that the proposed solution is feasible within the current stack. Flag any new infrastructure, services, or third-party dependencies in the Dependencies section.
23
246. **Flag assumptions** — Any statement that is not grounded in an existing doc or explicit user input goes into Open Questions. Be aggressive about surfacing unknowns.
25
267. **Write the file** — Save to `.chalk/docs/product/<n>_prd_<slug>.md`.
27
288. **Confirm** — Tell the user the PRD was created, share the file path, and highlight the top 2-3 open questions that need resolution before engineering work begins.
29
30## PRD Structure
31
32```markdown
33# PRD: <Feature Name>
34
35Last updated: <YYYY-MM-DD> (Initial draft)
36
37## Problem Statement
38
39What user problem are we solving and why does it matter now? Link to a Job-to-be-Done if one exists in the product docs. State the problem from the user's perspective, not the system's.
40
41## Target Users
42
43Who specifically experiences this problem? Use personas from product docs if available. Include:
44- Primary persona and their context
45- Secondary personas (if any)
46- Who this is NOT for (anti-personas)
47
48## Success Metrics
49
50How will we know this worked? Every metric must be:
51- Measurable (has a number or clear threshold)
52- Time-bound (measured over what period)
53- Baselined (current state vs. target state)
54
55| Metric | Current | Target | Timeframe |
56|--------|---------|--------|-----------|
57| ... | ... | ... | ... |
58
59## User Stories
60
61Group by user activity. Each story follows:
62
63**Activity: <activity name>**
64
65As a [persona], I want [action], so that [outcome].
66
67Acceptance Criteria:
68- Given [context], when [action], then [expected result]
69- Given [context], when [action], then [expected result]
70
71## Acceptance Criteria (Feature-Level)
72
73Testable conditions that must ALL be true for the feature to be considered complete. Write in Given/When/Then format. These are the contract between product and engineering.
74
75## Edge Cases
76
77Enumerate scenarios that are easy to overlook:
78- Error states (network failure, invalid input, timeout)
79- Empty states (first-time user, no data)
80- Boundary conditions (max limits, concurrent users, large payloads)
81- Permission boundaries (unauthorized access, expired sessions)
82- Backwards compatibility (existing users, data migration)
83
84## Out of Scope
85
86Explicitly list what this PRD does NOT cover. This section prevents scope creep and misaligned expectations. Be specific: "Real-time sync is out of scope" not "Some features are out of scope."
87
88## Dependencies
89
90- **Internal**: Other teams, services, or features that must exist first
91- **External**: Third-party APIs, vendor contracts, compliance requirements
92- **Technical**: Infrastructure, tooling, or architectural changes required
93
94## Open Questions
95
96Numbered list of unresolved items that block confident implementation. Each question should name who can answer it.
97
981. [Question] — Owner: [person/team]
99```
100
101## Output
102
103- **File**: `.chalk/docs/product/<n>_prd_<slug>.md`
104- **Format**: Plain markdown, no YAML frontmatter
105- **First line**: `# PRD: <Feature Name>`
106- **Second line**: `Last updated: <YYYY-MM-DD> (Initial draft)`
107
108## Anti-patterns
109
110- **Solution-first writing** — Never start with "We will build X." Start with the user problem. If the user gives you a solution ("add a button that..."), dig back to the underlying need.
111- **PRDs without success metrics** — A PRD with no measurable outcomes is a wish list. Every PRD needs at least 2 metrics with concrete targets.
112- **Missing out-of-scope section** — Omitting this guarantees scope creep. Even if the scope seems obvious, write it down.
113- **Vague acceptance criteria** — "The feature should work well" is not testable. Every criterion must follow Given/When/Then and be verifiable by QA without asking the PM what "well" means.
114- **Feature lists instead of user outcomes** — "Add filtering, sorting, and pagination" describes implementation, not value. Write "Users can find the specific record they need within 10 seconds" instead.
115- **Copy-pasting the template with blanks** — Every section must contain substantive content. If you genuinely don't have information for a section, move the gap to Open Questions and explain what's missing.
116- **Ignoring existing product context** — Always check `.chalk/docs/product/` first. PRDs that contradict the product profile or duplicate existing PRDs waste everyone's time.
majiayu000