Writing PRDs (Executable)
This skill turns messy ideas into shippable artifacts:
- PR/FAQ (customer-first narrative)
- PRD (scope + requirements + success metrics)
- AI Eval Spec (requirements as executable evals) — AI only
- Prompt Set / Prototype plan — AI only
Keep outputs crisp, concrete, and copy‑pasteable. Prefer bullets, tables, and numbered requirements over long prose.
When to use
Use this skill when the user requests:
- a PRD / product requirements / product spec / requirements doc
- a PR/FAQ or “working backwards” narrative
- acceptance criteria, rollout plan, risks, dependencies
- AI/LLM behavior requirements, evals, judge rubric, prompt sets
When NOT to use (redirect)
Do NOT use this skill as a substitute for:
- Company strategy / vision (use a vision/strategy skill)
- Roadmap prioritization across many initiatives (use prioritization/roadmap skill)
- Pure UX copywriting or marketing launch copy (use messaging/launch skills)
If legal/privacy/security constraints are material but unknown, first ask for constraints and the approval process.
Quick decision: which artifact(s) to produce
If the user doesn’t specify, choose the minimal artifact that unlocks the next decision:
- Early / unclear idea → PR/FAQ first, then a lightweight PRD outline.
- Clear direction, need alignment / build plan → PRD.
- AI/LLM feature → PRD + Eval Spec + Prompt Set (required).
- “Improve this existing PRD/spec” → rewrite + gaps + open questions.
Templates:
- PRD:
assets/PRD_TEMPLATE.md
- PR/FAQ:
assets/PRFAQ_TEMPLATE.md
- Eval Spec:
assets/EVAL_SPEC_TEMPLATE.md
- Prompt Set:
assets/PROMPT_SET_TEMPLATE.md
Quality checks:
- Checklist:
references/QUALITY_CHECKLIST.md
- Rubric:
references/QUALITY_RUBRIC.md
- Question bank:
references/QUESTION_BANK.md
Intake: ask only what you must
Ask at most 5 high-leverage questions at a time (use references/QUESTION_BANK.md).
If the user can’t answer, proceed with explicit assumptions.
Minimum inputs to proceed:
- Product/feature name + target user
- Problem statement (what pain / why now)
- Success metric(s) or a proxy
- Constraints (time, platform, legal, data, dependencies)
- Audience for the doc (exec decision? eng build? cross-functional alignment?)
Output contract (always include)
Always include:
- Version + date + owner (or “TBD”)
- Goals and non-goals
- Requirements as numbered bullets (R1, R2…)
- Clear “Out of scope”
- Open questions (with owner / next step)
When producing multiple artifacts, output in this order:
- PR/FAQ → 2) PRD → 3) Eval Spec → 4) Prompt Set
Workflow A: Draft a PR/FAQ (customer-first)
Use when the idea is early or benefits are fuzzy.
- Write the press release in external-facing, factual language.
- Add FAQs for: customer, internal stakeholders, technical/ops, risks.
- Include a hypothetical launch date (forces planning).
- Extract “claims” from the PR (what must be true) → convert to requirements.
Workflow B: Draft or rewrite a PRD (shippable requirements)
- Start with a 5–10 line narrative (why this matters, for whom).
- Define scope boundaries: goals, non-goals, assumptions.
- Define users + key journeys (happy path + edge cases).
- Translate into requirements:
- Functional requirements (R1…)
- Non-functional requirements (performance, reliability, accessibility, privacy)
- Define success metrics + instrumentation.
- Rollout plan + risks + mitigations.
- End with open questions + decision log.
Workflow C (AI only): Requirements as executable evals
Goal: make requirements testable.
- List non‑negotiable behaviors (MUST / MUST‑NOT).
- Build a test set: golden, adversarial, regression.
- Write an LLM‑as‑judge rubric (scale + definitions + pass threshold).
- Connect evals to shipping gates (pre‑launch + post‑launch monitoring).
Workflow D (AI only): Prompt set + prototype plan
- Provide a small prompt set that exercises core use cases + edge cases.
- Specify expected outputs and guardrails.
- Propose a minimal prototype plan if useful (what to mock vs build).
Quality bar (before finalizing)
Run:
references/QUALITY_CHECKLIST.md
references/QUALITY_RUBRIC.md
Also include a brief circulation plan: who should review (Eng, Design, Data, Support, Marketing, Legal) and what feedback you need from each.
Confidentiality
Treat user-provided information as confidential. Do not include secrets in outputs. If something looks sensitive, redact or replace with placeholders.
1---2name: writing-prds-executable3description: Draft, critique, or rewrite PRDs (product requirements / product specs) and adjacent artifacts (PR/FAQ, acceptance criteria, rollout plan). For AI/LLM features, also draft eval specs (LLM-as-judge) and prompt sets. Output must be in English. Use when the user asks for a PRD/spec/requirements/PRFAQ/evals/prompt sets, or needs help clarifying scope, success metrics, non-goals, user stories, or stakeholder alignment.4---5
6# Writing PRDs (Executable)
7
8This skill turns messy ideas into **shippable artifacts**:
91) PR/FAQ (customer-first narrative)
102) PRD (scope + requirements + success metrics)
113) AI Eval Spec (requirements as executable evals) — AI only
124) Prompt Set / Prototype plan — AI only
13
14Keep outputs crisp, concrete, and copy‑pasteable. Prefer bullets, tables, and numbered requirements over long prose.
15
16## When to use
17
18Use this skill when the user requests:
19- a PRD / product requirements / product spec / requirements doc
20- a PR/FAQ or “working backwards” narrative
21- acceptance criteria, rollout plan, risks, dependencies
22- AI/LLM behavior requirements, evals, judge rubric, prompt sets
23
24## When NOT to use (redirect)
25
26Do NOT use this skill as a substitute for:
27- Company strategy / vision (use a vision/strategy skill)
28- Roadmap prioritization across many initiatives (use prioritization/roadmap skill)
29- Pure UX copywriting or marketing launch copy (use messaging/launch skills)
30
31If legal/privacy/security constraints are material but unknown, first ask for constraints and the approval process.
32
33## Quick decision: which artifact(s) to produce
34
35If the user doesn’t specify, choose the minimal artifact that unlocks the next decision:
36
37- Early / unclear idea → **PR/FAQ** first, then a lightweight PRD outline.
38- Clear direction, need alignment / build plan → **PRD**.
39- AI/LLM feature → **PRD + Eval Spec + Prompt Set** (required).
40- “Improve this existing PRD/spec” → rewrite + gaps + open questions.
41
42Templates:
43- PRD: `assets/PRD_TEMPLATE.md`
44- PR/FAQ: `assets/PRFAQ_TEMPLATE.md`
45- Eval Spec: `assets/EVAL_SPEC_TEMPLATE.md`
46- Prompt Set: `assets/PROMPT_SET_TEMPLATE.md`
47
48Quality checks:
49- Checklist: `references/QUALITY_CHECKLIST.md`
50- Rubric: `references/QUALITY_RUBRIC.md`
51- Question bank: `references/QUESTION_BANK.md`
52
53## Intake: ask only what you must
54
55Ask at most **5** high-leverage questions at a time (use `references/QUESTION_BANK.md`).
56If the user can’t answer, proceed with explicit assumptions.
57
58Minimum inputs to proceed:
591) Product/feature name + target user
602) Problem statement (what pain / why now)
613) Success metric(s) or a proxy
624) Constraints (time, platform, legal, data, dependencies)
635) Audience for the doc (exec decision? eng build? cross-functional alignment?)
64
65## Output contract (always include)
66
67Always include:
68- Version + date + owner (or “TBD”)
69- Goals and non-goals
70- Requirements as numbered bullets (R1, R2…)
71- Clear “Out of scope”
72- Open questions (with owner / next step)
73
74When producing multiple artifacts, output in this order:
751) PR/FAQ → 2) PRD → 3) Eval Spec → 4) Prompt Set
76
77## Workflow A: Draft a PR/FAQ (customer-first)
78
79Use when the idea is early or benefits are fuzzy.
80
811) Write the press release in external-facing, factual language.
822) Add FAQs for: customer, internal stakeholders, technical/ops, risks.
833) Include a hypothetical launch date (forces planning).
844) Extract “claims” from the PR (what must be true) → convert to requirements.
85
86## Workflow B: Draft or rewrite a PRD (shippable requirements)
87
881) Start with a 5–10 line narrative (why this matters, for whom).
892) Define scope boundaries: goals, non-goals, assumptions.
903) Define users + key journeys (happy path + edge cases).
914) Translate into requirements:
92 - Functional requirements (R1…)
93 - Non-functional requirements (performance, reliability, accessibility, privacy)
945) Define success metrics + instrumentation.
956) Rollout plan + risks + mitigations.
967) End with open questions + decision log.
97
98## Workflow C (AI only): Requirements as executable evals
99
100Goal: make requirements testable.
101
1021) List non‑negotiable behaviors (MUST / MUST‑NOT).
1032) Build a test set: golden, adversarial, regression.
1043) Write an LLM‑as‑judge rubric (scale + definitions + pass threshold).
1054) Connect evals to shipping gates (pre‑launch + post‑launch monitoring).
106
107## Workflow D (AI only): Prompt set + prototype plan
108
1091) Provide a small prompt set that exercises core use cases + edge cases.
1102) Specify expected outputs and guardrails.
1113) Propose a minimal prototype plan if useful (what to mock vs build).
112
113## Quality bar (before finalizing)
114
115Run:
116- `references/QUALITY_CHECKLIST.md`
117- `references/QUALITY_RUBRIC.md`
118
119Also include a brief circulation plan: who should review (Eng, Design, Data, Support, Marketing, Legal) and what feedback you need from each.
120
121## Confidentiality
122
123Treat user-provided information as confidential. Do not include secrets in outputs. If something looks sensitive, redact or replace with placeholders.