prd-authoring

Name: prd-authoring
Author: Productfculty-aipm

70stars33forks

How to install prd-authoring?

productfculty-aipm/pm-copilot-by-product-faculty/prd-authoring

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill prd-authoring

Installs into the current project.

Summary

Use this skill when the user asks to "write a PRD", "write a spec", "product requirements document", "generate a PRD", "turn this into a spec", "create product requirements", "write acceptance criteria", or explicitly asks for a PRD or product specification. This skill writes a f

Files · 1

View on GitHub

SKILL.md

1	# PRD Authoring
2
3	You are writing a production-ready PRD. The PRD should be complete enough to hand to an engineer and start building — but no longer than needed to achieve that bar.
4
5	Frameworks: Lenny's PRD guide (problem-oriented, clear success criteria, just enough direction, urgency, short), Alberto Savoia (pretotype thinking), Pyramid Principle.
6
7	Key principle from Lenny: "The best PRDs are problem-oriented. They define the problem so clearly that an engineer could propose a better solution than the PM did." — Lenny's PRD guide
8
9	## Step 1 — Load Context
10
11	Read in parallel:
12	- `memory/user-profile.md` — PRD format preference (brief / detailed / bullet-heavy / narrative), product context, stakeholders
13	- `context/product/personas.md` (fallback: template)
14	- `context/product/roadmap.md` (fallback: template) — for OKR linkage and strategic fit
15	- `context/company/analytics-baseline.md` — for realistic success metrics
16	- `context/company/past-prds.md` — if it exists, match the team's tone and level of detail
17	- `context/templates/prd-template.md` — the output template
18
19	Apply `prd_format_preference` from memory. If "brief", keep sections tight. If "detailed", expand with examples.
20
21	## Step 2 — Parse the Input
22
23	Extract from the user's input:
24	- The feature or initiative being specced
25	- The user problem it solves (if stated; if not, infer from context)
26	- Any constraints or requirements already stated
27	- Any stakeholders or review requirements mentioned
28
29	## Step 3 — Clarify If Needed (One Question Only)
30
31	If the input is too vague to write a PRD (e.g., "write a PRD about AI"), ask ONE clarifying question:
32	"What specific problem are you trying to solve with this? Who is affected and what are they doing today?"
33
34	Do not ask multiple questions. If the problem is somewhat clear, proceed and document assumptions in Open Questions.
35
36	## Step 4 — Write the PRD
37
38	Fill in every section of `context/templates/prd-template.md`:
39
40	Problem: Be specific. Name the persona, describe the situation, quantify the pain where possible. The problem section should make it obvious why this is worth building now.
41
42	Users: Pull from `personas.md`. Primary user = most affected. User stories should be demand-side: "When [struggling moment], I want to [action] so I can [progress]."
43
44	Solution: Describe the core mechanic. Include explicit out-of-scope items — minimum 2. These prevent scope creep and make alignment faster.
45
46	Key Flows: Write 2–3 flows covering: (1) happy path, (2) an edge case or alternative path. Each flow should be numbered steps, not prose.
47
48	System Architecture (AI features only): If AI/ML is involved, specify model tier, prompt structure, retrieval layer, eval framework, and AI-specific failure modes. If not AI: skip this section.
49
50	Acceptance Criteria: 4–6 binary criteria. Each must be testable in isolation by QA. Avoid: "the feature works correctly" (not testable). Use: "When a user [action], the system [specific response] within [time/condition]."
51
52	Edge Cases & Failure Modes: At least 3 scenarios. Include: empty state, error state, and at least one scenario that would surprise a junior engineer.
53
54	Success Metrics: 2–3 metrics with baseline, target, timeframe, and measurement method. All must be outcome-oriented and measurable within 30 days of ship.
55
56	Open Questions: List assumptions made. Flag the one assumption that, if wrong, would most change the spec. Every high-priority open question should have an owner.
57
58	Dependencies & Risks: Be specific about what must be true before shipping and what could derail it.
59
60	## Step 5 — AI Feature Handling
61
62	If the feature involves AI, expand the System Architecture section:
63	- Model recommendation: claude-haiku-4-5 (fast, cheap, routine tasks), claude-sonnet-4-6 (balanced quality/cost, most PM tasks), claude-opus-4-6 (complex reasoning, strategy)
64	- Prompt structure: What does the system prompt instruct? What does the user message contain?
65	- Context window needs: What context does the model need per request?
66	- Eval framework: How will quality be measured? What's the minimum bar to ship?
67	- Failure modes: Hallucination (how detected?), latency spike (UX fallback?), cost overrun (guard and alert?)
68
69	## Step 6 — Quality Check
70
71	Before outputting, verify:
72	- [ ] Every bracketed placeholder is replaced
73	- [ ] At least 2 explicit out-of-scope items
74	- [ ] At least 1 failu

Productfculty-aipmPublisher · 69 listings

Preview

Productfculty-aipm/PM-Copilot-by-Product-Faculty

# PRD Authoring

You are writing a production-ready PRD. The PRD should be complete enough to hand to an engineer and start building — but no longer than needed to achieve that

Frameworks: Lenny's PRD guide (problem-oriented, clear success criteria, just enough direction, urgency, short), Alberto Savoia (pretotype thinking), Pyramid Pr

Key principle from Lenny: "The best PRDs are problem-oriented. They define the problem so clearly that an engineer could propose a better solution than the PM d

RepoProductfculty-aipm/PM-Copilot-by-Product-Faculty

License—

TypeSkills

CategoryPlanning

UpdatedApr 2026

Repo stars70

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

prd-authoring

70stars33forks

View on GitHub

How to install prd-authoring?

productfculty-aipm/pm-copilot-by-product-faculty/prd-authoring

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill prd-authoring

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PRD Authoring
2
3	You are writing a production-ready PRD. The PRD should be complete enough to hand to an engineer and start building — but no longer than needed to achieve that bar.
4
5	Frameworks: Lenny's PRD guide (problem-oriented, clear success criteria, just enough direction, urgency, short), Alberto Savoia (pretotype thinking), Pyramid Principle.
6
7	Key principle from Lenny: "The best PRDs are problem-oriented. They define the problem so clearly that an engineer could propose a better solution than the PM did." — Lenny's PRD guide
8
9	## Step 1 — Load Context
10
11	Read in parallel:
12	- `memory/user-profile.md` — PRD format preference (brief / detailed / bullet-heavy / narrative), product context, stakeholders
13	- `context/product/personas.md` (fallback: template)
14	- `context/product/roadmap.md` (fallback: template) — for OKR linkage and strategic fit
15	- `context/company/analytics-baseline.md` — for realistic success metrics
16	- `context/company/past-prds.md` — if it exists, match the team's tone and level of detail
17	- `context/templates/prd-template.md` — the output template
18
19	Apply `prd_format_preference` from memory. If "brief", keep sections tight. If "detailed", expand with examples.
20
21	## Step 2 — Parse the Input
22
23	Extract from the user's input:
24	- The feature or initiative being specced
25	- The user problem it solves (if stated; if not, infer from context)
26	- Any constraints or requirements already stated
27	- Any stakeholders or review requirements mentioned
28
29	## Step 3 — Clarify If Needed (One Question Only)
30
31	If the input is too vague to write a PRD (e.g., "write a PRD about AI"), ask ONE clarifying question:
32	"What specific problem are you trying to solve with this? Who is affected and what are they doing today?"
33
34	Do not ask multiple questions. If the problem is somewhat clear, proceed and document assumptions in Open Questions.
35
36	## Step 4 — Write the PRD
37
38	Fill in every section of `context/templates/prd-template.md`:
39
40	Problem: Be specific. Name the persona, describe the situation, quantify the pain where possible. The problem section should make it obvious why this is worth building now.
41
42	Users: Pull from `personas.md`. Primary user = most affected. User stories should be demand-side: "When [struggling moment], I want to [action] so I can [progress]."
43
44	Solution: Describe the core mechanic. Include explicit out-of-scope items — minimum 2. These prevent scope creep and make alignment faster.
45
46	Key Flows: Write 2–3 flows covering: (1) happy path, (2) an edge case or alternative path. Each flow should be numbered steps, not prose.
47
48	System Architecture (AI features only): If AI/ML is involved, specify model tier, prompt structure, retrieval layer, eval framework, and AI-specific failure modes. If not AI: skip this section.
49
50	Acceptance Criteria: 4–6 binary criteria. Each must be testable in isolation by QA. Avoid: "the feature works correctly" (not testable). Use: "When a user [action], the system [specific response] within [time/condition]."
51
52	Edge Cases & Failure Modes: At least 3 scenarios. Include: empty state, error state, and at least one scenario that would surprise a junior engineer.
53
54	Success Metrics: 2–3 metrics with baseline, target, timeframe, and measurement method. All must be outcome-oriented and measurable within 30 days of ship.
55
56	Open Questions: List assumptions made. Flag the one assumption that, if wrong, would most change the spec. Every high-priority open question should have an owner.
57
58	Dependencies & Risks: Be specific about what must be true before shipping and what could derail it.
59
60	## Step 5 — AI Feature Handling
61
62	If the feature involves AI, expand the System Architecture section:
63	- Model recommendation: claude-haiku-4-5 (fast, cheap, routine tasks), claude-sonnet-4-6 (balanced quality/cost, most PM tasks), claude-opus-4-6 (complex reasoning, strategy)
64	- Prompt structure: What does the system prompt instruct? What does the user message contain?
65	- Context window needs: What context does the model need per request?
66	- Eval framework: How will quality be measured? What's the minimum bar to ship?
67	- Failure modes: Hallucination (how detected?), latency spike (UX fallback?), cost overrun (guard and alert?)
68
69	## Step 6 — Quality Check
70
71	Before outputting, verify:
72	- [ ] Every bracketed placeholder is replaced
73	- [ ] At least 2 explicit out-of-scope items
74	- [ ] At least 1 failu

Productfculty-aipmPublisher · 69 listings

Preview

Productfculty-aipm/PM-Copilot-by-Product-Faculty

# PRD Authoring

You are writing a production-ready PRD. The PRD should be complete enough to hand to an engineer and start building — but no longer than needed to achieve that

Frameworks: Lenny's PRD guide (problem-oriented, clear success criteria, just enough direction, urgency, short), Alberto Savoia (pretotype thinking), Pyramid Pr

Key principle from Lenny: "The best PRDs are problem-oriented. They define the problem so clearly that an engineer could propose a better solution than the PM d

RepoProductfculty-aipm/PM-Copilot-by-Product-Faculty

License—

TypeSkills

CategoryPlanning

UpdatedApr 2026

Repo stars70

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type