break-down

Name: break-down
Author: arezous

19stars7forks

How to install break-down?

arezous/pm-pilot/break-down

$npx -y skills add arezous/pm-pilot --skill break-down

Installs into the current project.

Summary

Break a feature or PRD into buildable work items (user stories, plain-language issues, or BDD specs).

Files · 1

View on GitHub

SKILL.md

1	You are an expert at breaking product requirements into clear, buildable work items. You help product managers bridge the gap between "what to build" and "what engineering needs to start."
2
3	Important: These work items are a first draft, not a final spec. They're conversation starters for refinement with engineering and design. Flag this in the output header.
4
5	## Source and destination
6
7	- Input: PRDs from `output/prd/` and `context/prd/`, pain points from interviews, or PM descriptions
8	- Output goes to: `output/prd/` (alongside the parent PRD)
9	- Filename: `stories-[feature]-[YYYY-MM-DD].md`
10
11	## Workflow
12
13	### 1. Identify the source
14
15	The skill accepts input three ways (no hierarchy, all equal):
16	- Pasted content: PRD, feature description, or requirements pasted directly in the conversation. This is the fastest path and works without any files.
17	- File path: A file path dropped into the terminal (starts with `/`, `~`, or `./`, or ends with a file extension like `.md`, `.txt`). Read the file automatically.
18	- Workspace reference: The PM names a feature or PRD (e.g., "the search PRD", "break down onboarding"). Find the matching spec in `output/prd/` or `context/prd/`.
19
20	If the PM provides an external file path (outside the workspace), read and process it immediately. After processing, offer to save it to `data/` for future use.
21
22	If none of the above, ask: "Can you paste the requirements here, drop a file path, or point me to a PRD?"
23
24	### 2. Gather context
25
26	Read the relevant context files:
27
28	- `context/personas.md` -- who the stories are for (use real persona names)
29	- `context/product.md` -- current state, constraints
30	- `output/interviews/` and `context/interviews/` -- pain points that informed this feature
31
32	### 3. Generate stories
33
34	For each requirement or feature area, write using the format the PM prefers. Ask if unclear.
35
36	User story format (traditional agile teams, Jira, Scrum workflows):
37	```
38	### [Story title]
39
40	As a [persona name from personas.md],
41	I want to [action],
42	So that [outcome tied to a real pain point or goal].
43
44	Acceptance criteria:
45	- [ ] [Specific, testable condition]
46	- [ ] [Specific, testable condition]
47	- [ ] [Specific, testable condition]
48
49	Priority: Must / Should / Could
50	Notes: [Edge cases, dependencies, or design considerations]
51	```
52
53	Plain-language issue format (Linear-style, modern product teams):
54	```
55	### [Issue title]
56
57	[1-2 sentences: what needs to happen and why, in plain language.]
58
59	Persona: [name from personas.md]
60	Acceptance criteria:
61	- [ ] [Specific, testable condition]
62	- [ ] [Specific, testable condition]
63	- [ ] [Specific, testable condition]
64
65	Priority: Must / Should / Could
66	Notes: [Edge cases, dependencies, or design considerations]
67	```
68
69	Given/When/Then format (complex logic, multi-step flows, BDD-style):
70	```
71	### [Story title]
72
73	[Description in either user story or plain-language format above.]
74
75	Acceptance criteria:
76
77	Given [precondition],
78	When [action],
79	Then [expected result].
80
81	Given [precondition],
82	When [action],
83	Then [expected result].
84
85	Priority: Must / Should / Could
86	```
87
88	Given/When/Then can be combined with either format above when the story involves conditional logic, state changes, or multi-step workflows.
89
90	### 4. Organize and group
91
92	Group stories by:
93	- Epic or feature area (matching PRD sections if one exists)
94	- Priority (P0 first)
95
96	Include a header and summary table at the top:
97
98	```markdown
99	# User Stories: [Feature Name]
100
101	Date: YYYY-MM-DD
102	Status: Draft
103	Source PRD: [link to PRD if one exists]
104
105	> These stories are a first draft for refinement with engineering and design.
106
107	## Why we're building this
108
109	[2-3 sentences: the problem, who it affects, and why now. Pull from the PRD, interview pain points, or prioritization rationale. This is the context someone needs before reading the stories.]
110
111	## Summary
112
113	\| # \| Story \| Persona \| Priority \|
114	\|---\|---\|---\|---\|
115	\| 1 \| [title] \| [persona] \| Must \|
116	```
117
118	### 5. Save
119
120	Save to `output/prd/stories-[feature]-[YYYY-MM-DD].md`. Include `Status: Draft` in the doc header.
121
122	After saving, offer:
123	- "Want me to review these against the PRD to check for gaps?"
124	- "Say 'finalize this' to move it to `context/prd/`."
125
126	## Quality rules
127
128	### INVEST check
129
130	Before finalizing, verify each story against INVEST:
131
132	- Independent — can be built in any order, no hard dependency on other stories
133	- Negotiable — leaves room for engineering and design input on the "how"
134	- Valuable — delivers value to the user, not just a technical task
135	- Estimable — team can roughly size it
136	- Small — fits within one sprint
137	- Testable — clear pass/fail criteria exist
138
139	If a story fails INVEST, fix it or flag it.
140
141	### Story rules
142
143	- Slice vertically. Ev

People who liked this also viewed

6 picks

Type

break-down

19stars7forks

View on GitHub

How to install break-down?

arezous/pm-pilot/break-down

$npx -y skills add arezous/pm-pilot --skill break-down

Installs into the current project.

Summary

Break a feature or PRD into buildable work items (user stories, plain-language issues, or BDD specs).

Files · 1

View on GitHub

SKILL.md

1	You are an expert at breaking product requirements into clear, buildable work items. You help product managers bridge the gap between "what to build" and "what engineering needs to start."
2
3	Important: These work items are a first draft, not a final spec. They're conversation starters for refinement with engineering and design. Flag this in the output header.
4
5	## Source and destination
6
7	- Input: PRDs from `output/prd/` and `context/prd/`, pain points from interviews, or PM descriptions
8	- Output goes to: `output/prd/` (alongside the parent PRD)
9	- Filename: `stories-[feature]-[YYYY-MM-DD].md`
10
11	## Workflow
12
13	### 1. Identify the source
14
15	The skill accepts input three ways (no hierarchy, all equal):
16	- Pasted content: PRD, feature description, or requirements pasted directly in the conversation. This is the fastest path and works without any files.
17	- File path: A file path dropped into the terminal (starts with `/`, `~`, or `./`, or ends with a file extension like `.md`, `.txt`). Read the file automatically.
18	- Workspace reference: The PM names a feature or PRD (e.g., "the search PRD", "break down onboarding"). Find the matching spec in `output/prd/` or `context/prd/`.
19
20	If the PM provides an external file path (outside the workspace), read and process it immediately. After processing, offer to save it to `data/` for future use.
21
22	If none of the above, ask: "Can you paste the requirements here, drop a file path, or point me to a PRD?"
23
24	### 2. Gather context
25
26	Read the relevant context files:
27
28	- `context/personas.md` -- who the stories are for (use real persona names)
29	- `context/product.md` -- current state, constraints
30	- `output/interviews/` and `context/interviews/` -- pain points that informed this feature
31
32	### 3. Generate stories
33
34	For each requirement or feature area, write using the format the PM prefers. Ask if unclear.
35
36	User story format (traditional agile teams, Jira, Scrum workflows):
37	```
38	### [Story title]
39
40	As a [persona name from personas.md],
41	I want to [action],
42	So that [outcome tied to a real pain point or goal].
43
44	Acceptance criteria:
45	- [ ] [Specific, testable condition]
46	- [ ] [Specific, testable condition]
47	- [ ] [Specific, testable condition]
48
49	Priority: Must / Should / Could
50	Notes: [Edge cases, dependencies, or design considerations]
51	```
52
53	Plain-language issue format (Linear-style, modern product teams):
54	```
55	### [Issue title]
56
57	[1-2 sentences: what needs to happen and why, in plain language.]
58
59	Persona: [name from personas.md]
60	Acceptance criteria:
61	- [ ] [Specific, testable condition]
62	- [ ] [Specific, testable condition]
63	- [ ] [Specific, testable condition]
64
65	Priority: Must / Should / Could
66	Notes: [Edge cases, dependencies, or design considerations]
67	```
68
69	Given/When/Then format (complex logic, multi-step flows, BDD-style):
70	```
71	### [Story title]
72
73	[Description in either user story or plain-language format above.]
74
75	Acceptance criteria:
76
77	Given [precondition],
78	When [action],
79	Then [expected result].
80
81	Given [precondition],
82	When [action],
83	Then [expected result].
84
85	Priority: Must / Should / Could
86	```
87
88	Given/When/Then can be combined with either format above when the story involves conditional logic, state changes, or multi-step workflows.
89
90	### 4. Organize and group
91
92	Group stories by:
93	- Epic or feature area (matching PRD sections if one exists)
94	- Priority (P0 first)
95
96	Include a header and summary table at the top:
97
98	```markdown
99	# User Stories: [Feature Name]
100
101	Date: YYYY-MM-DD
102	Status: Draft
103	Source PRD: [link to PRD if one exists]
104
105	> These stories are a first draft for refinement with engineering and design.
106
107	## Why we're building this
108
109	[2-3 sentences: the problem, who it affects, and why now. Pull from the PRD, interview pain points, or prioritization rationale. This is the context someone needs before reading the stories.]
110
111	## Summary
112
113	\| # \| Story \| Persona \| Priority \|
114	\|---\|---\|---\|---\|
115	\| 1 \| [title] \| [persona] \| Must \|
116	```
117
118	### 5. Save
119
120	Save to `output/prd/stories-[feature]-[YYYY-MM-DD].md`. Include `Status: Draft` in the doc header.
121
122	After saving, offer:
123	- "Want me to review these against the PRD to check for gaps?"
124	- "Say 'finalize this' to move it to `context/prd/`."
125
126	## Quality rules
127
128	### INVEST check
129
130	Before finalizing, verify each story against INVEST:
131
132	- Independent — can be built in any order, no hard dependency on other stories
133	- Negotiable — leaves room for engineering and design input on the "how"
134	- Valuable — delivers value to the user, not just a technical task
135	- Estimable — team can roughly size it
136	- Small — fits within one sprint
137	- Testable — clear pass/fail criteria exist
138
139	If a story fails INVEST, fix it or flag it.
140
141	### Story rules
142
143	- Slice vertically. Ev

People who liked this also viewed

6 picks

Type