evanflow-prd

Name: evanflow-prd
Author: evanklem

419stars18forks

How to install evanflow-prd?

evanklem/evanflow/evanflow-prd

$npx -y skills add evanklem/evanflow --skill evanflow-prd

Installs into the current project.

Summary

Synthesize a PRD (Product Requirements Document) for a big new feature. Synthesis (not interview) — uses existing project context and explicit ADRs. Asks before gh issue create. Use when scoping a substantial new feature in PRD shape (e.g., before a sprint).

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: PRD
2
3
4	## Vocabulary
5
6	See `evanflow` meta-skill.
7
8	## When to Use
9
10	- Substantial new feature requiring stakeholder alignment
11	- Pre-sprint scoping
12	- A spec exists in conversation but needs structured form for the team
13
14	SKIP when: the work is small enough for `evanflow-brainstorming` → `evanflow-writing-plans` directly.
15
16	## The Flow
17
18	### 1. Read Context (don't interview)
19
20	The skill name is "to-prd" not "interview-to-prd" for a reason. Synthesize from what's already known:
21
22	- `CLAUDE.md` for project conventions
23	- `CONTEXT.md` for domain language
24	- `docs/adr/` for prior architectural decisions
25	- Recent commits and `docs/stakeholder/*.md` for in-flight initiatives
26	- The conversation up to this point
27
28	Only ask the user for things you genuinely cannot derive.
29
30	### 2. Identify Major Modules
31
32	Sketch the modules to build/modify, emphasizing deep modules (small interface, complex internals). Apply the deletion test to each — does this module earn its existence?
33
34	### 3. Validate Architecture
35
36	Confirm with the user:
37
38	- The module list (correct, exhaustive, no gaps)
39	- Which components require test coverage (you can't test everything)
40	- Which existing patterns to follow vs. diverge from
41
42	### 4. Write the PRD
43
44	Default location: `docs/specs/YYYY-MM-DD-<feature>.md`. Use the user's preferred path if they have one.
45
46	Structure:
47
48	```markdown
49	# [Feature Name] PRD
50
51	## Problem
52
53	One paragraph: what's broken or missing in the current product, and who feels the pain.
54
55	## Solution
56
57	One paragraph: the shape of the answer, named in domain language.
58
59	## User stories
60
61	- As a <role>, I can <action> so that <outcome>.
62	- (List 5-15)
63
64	## Architecture
65
66	Module list with one-line responsibility per module. Reference existing files where relevant. No code paths.
67
68	## Testing strategy
69
70	What behaviors must be covered. Integration vs. unit. Real services vs. test doubles.
71
72	## Scope
73
74	In:
75	- ...
76
77	Out:
78	- ...
79
80	## Open questions
81
82	Things needing decision before the plan can be written.
83	```
84
85	### 5. Optional: Create GitHub Issue
86
87	If the user wants the PRD as a GitHub issue, ASK before running `gh issue create`. Never auto-file.
88
89	## Hard Rules
90
91	- Synthesize, don't interrogate. Ask only for genuinely unknown things.
92	- Domain language from `CONTEXT.md`. Use canonical terms.
93	- External behavior over implementation. Testing strategy describes what to verify, not how.
94	- Asks before `gh issue create`. No auto-file.
95	- Never auto-commit. PRD doc gets staged; user confirms before commit.
96
97	## Hand-offs
98
99	- PRD approved, ready for plan → `evanflow-writing-plans`. If the PRD's module list shows 3+ independent components sharing a contract, the plan should be structured for `evanflow-coder-overseer`.
100	- New domain terms emerged → `evanflow-glossary` to update `CONTEXT.md`
101	- PRD reveals architecture concerns → `evanflow-improve-architecture` first
102	- PRD's interface design needs more thought → `evanflow-design-interface` before plan

People who liked this also viewed

6 picks

Type

evanflow-prd

419stars18forks

View on GitHub

How to install evanflow-prd?

evanklem/evanflow/evanflow-prd

$npx -y skills add evanklem/evanflow --skill evanflow-prd

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: PRD
2
3
4	## Vocabulary
5
6	See `evanflow` meta-skill.
7
8	## When to Use
9
10	- Substantial new feature requiring stakeholder alignment
11	- Pre-sprint scoping
12	- A spec exists in conversation but needs structured form for the team
13
14	SKIP when: the work is small enough for `evanflow-brainstorming` → `evanflow-writing-plans` directly.
15
16	## The Flow
17
18	### 1. Read Context (don't interview)
19
20	The skill name is "to-prd" not "interview-to-prd" for a reason. Synthesize from what's already known:
21
22	- `CLAUDE.md` for project conventions
23	- `CONTEXT.md` for domain language
24	- `docs/adr/` for prior architectural decisions
25	- Recent commits and `docs/stakeholder/*.md` for in-flight initiatives
26	- The conversation up to this point
27
28	Only ask the user for things you genuinely cannot derive.
29
30	### 2. Identify Major Modules
31
32	Sketch the modules to build/modify, emphasizing deep modules (small interface, complex internals). Apply the deletion test to each — does this module earn its existence?
33
34	### 3. Validate Architecture
35
36	Confirm with the user:
37
38	- The module list (correct, exhaustive, no gaps)
39	- Which components require test coverage (you can't test everything)
40	- Which existing patterns to follow vs. diverge from
41
42	### 4. Write the PRD
43
44	Default location: `docs/specs/YYYY-MM-DD-<feature>.md`. Use the user's preferred path if they have one.
45
46	Structure:
47
48	```markdown
49	# [Feature Name] PRD
50
51	## Problem
52
53	One paragraph: what's broken or missing in the current product, and who feels the pain.
54
55	## Solution
56
57	One paragraph: the shape of the answer, named in domain language.
58
59	## User stories
60
61	- As a <role>, I can <action> so that <outcome>.
62	- (List 5-15)
63
64	## Architecture
65
66	Module list with one-line responsibility per module. Reference existing files where relevant. No code paths.
67
68	## Testing strategy
69
70	What behaviors must be covered. Integration vs. unit. Real services vs. test doubles.
71
72	## Scope
73
74	In:
75	- ...
76
77	Out:
78	- ...
79
80	## Open questions
81
82	Things needing decision before the plan can be written.
83	```
84
85	### 5. Optional: Create GitHub Issue
86
87	If the user wants the PRD as a GitHub issue, ASK before running `gh issue create`. Never auto-file.
88
89	## Hard Rules
90
91	- Synthesize, don't interrogate. Ask only for genuinely unknown things.
92	- Domain language from `CONTEXT.md`. Use canonical terms.
93	- External behavior over implementation. Testing strategy describes what to verify, not how.
94	- Asks before `gh issue create`. No auto-file.
95	- Never auto-commit. PRD doc gets staged; user confirms before commit.
96
97	## Hand-offs
98
99	- PRD approved, ready for plan → `evanflow-writing-plans`. If the PRD's module list shows 3+ independent components sharing a contract, the plan should be structured for `evanflow-coder-overseer`.
100	- New domain terms emerged → `evanflow-glossary` to update `CONTEXT.md`
101	- PRD reveals architecture concerns → `evanflow-improve-architecture` first
102	- PRD's interface design needs more thought → `evanflow-design-interface` before plan

People who liked this also viewed

6 picks

Type