happy-path-scope

Name: happy-path-scope
Author: Productfculty-aipm

70stars33forks

How to install happy-path-scope?

productfculty-aipm/pm-copilot-by-product-faculty/happy-path-scope

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill happy-path-scope

Installs into the current project.

Summary

Use this skill when the user asks to "scope this to the happy path", "what's the minimum I need to prototype", "help me cut scope for prototyping", "what should I include in the prototype", "how do I decide what to prototype", or needs help deciding which parts of a feature to in

Files · 1

View on GitHub

SKILL.md

1	# Happy Path Scoping
2
3	You are helping the user scope a prototype to the minimum needed for its purpose. Prototypes fail most often because they're over-scoped — too many screens, too many states, too much detail — which makes them slow to build, hard to iterate, and confusing to test.
4
5	Framework: Colin Matthews (prototype scope discipline), Shape Up (appetite-based scoping applied to prototypes).
6
7	Key principle: A prototype should contain only what's needed to answer the question it's designed to answer. Every screen and state beyond that is waste.
8
9	## Step 1 — Clarify the Prototype's Purpose
10
11	Before scoping, ask: what is this prototype for?
12
13	User testing: The prototype needs to be realistic enough that users can complete the task without confusion. Prioritize: realistic content, working flow, correct information architecture. De-prioritize: visual polish, error states, edge cases.
14
15	Stakeholder demo / alignment: The prototype needs to communicate the vision. Prioritize: key screens, the "wow moment", one complete flow. De-prioritize: completeness, all edge cases, mobile version.
16
17	Engineering spec / handoff: The prototype needs to demonstrate the interaction mechanics. Prioritize: interactive states, transitions, behavior on action. De-prioritize: visual perfection, backend-dependent behavior.
18
19	Team alignment / discussion: The prototype needs to ground a conversation. Prioritize: the two or three screens in dispute. De-prioritize: everything else.
20
21	## Step 2 — Define the Happy Path
22
23	The happy path is the sequence of steps where:
24	- The user knows exactly what to do
25	- Every input is valid
26	- Every system response succeeds
27	- The user achieves their goal
28
29	Map the happy path for the feature being prototyped:
30	1. [Step 1] — [User action]
31	2. [Step 2] — [System response]
32	3. [Step 3] — [User action]
33	...
34	N. [Outcome] — [User has achieved their goal]
35
36	This becomes the spine of the prototype. Everything else is a branch — don't prototype branches.
37
38	## Step 3 — Cut List
39
40	For each of the following, decide: In prototype or Out of prototype
41
42	\| Element \| Include? \| Why \|
43	\|---\|---\|---\|
44	\| Auth / login flow \| OUT \| Start logged in. Auth is a solved problem. \|
45	\| Empty states \| OUT \| Use mock data instead. \|
46	\| Error messages / validation \| OUT \| Happy path only. \|
47	\| Loading states \| OUT \| Mock instant load. \|
48	\| Settings / configuration \| OUT \| Not in the happy path. \|
49	\| Admin / internal views \| OUT \| Not the user's journey. \|
50	\| Mobile responsive \| OUT \| Unless this IS a mobile test. \|
51	\| [Feature-specific element] \| [In/Out] \| [Reason] \|
52
53	## Step 4 — Minimum Screen Count
54
55	Force a minimum screen count:
56
57	For user testing: You need at least 3 screens (start state, mid-flow, success state). You rarely need more than 7.
58
59	For stakeholder demo: You need the "before" (the problem state) and the "after" (the solution working). 2–4 screens is typical.
60
61	For engineering spec: You need every unique interaction state. Count the number of distinct interactions, not screens.
62
63	If the prototype has more than 8 screens, scope it down until it fits. Prototype one flow completely rather than two flows partially.
64
65	## Step 5 — Mock Data Requirements
66
67	Define the mock data needed to make the prototype feel real:
68
69	- How many items in each list? (3–5 is almost always enough)
70	- What are the realistic values? (Use real names, real product language, real numbers)
71	- What's the "interesting" example? (The one that best illustrates the feature's value)
72
73	## Step 6 — Output
74
75	Produce:
76	- Happy path definition (numbered steps)
77	- Screen list (only what's in scope)
78	- Cut list (what's excluded and why)
79	- Mock data requirements
80	- Prototype scope statement: "This prototype shows [user type] doing [action] to achieve [goal]. It does NOT show [list of exclusions]."
81
82	This scope statement should be shared whenever the prototype is shared, to prevent misunderstanding about what's implemented.

Productfculty-aipmPublisher · 69 listings

Preview

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

# Happy Path Scoping

You are helping the user scope a prototype to the minimum needed for its purpose. Prototypes fail most often because they're over-scoped — too many screens, too

Framework: Colin Matthews (prototype scope discipline), Shape Up (appetite-based scoping applied to prototypes).

Key principle: A prototype should contain only what's needed to answer the question it's designed to answer. Every screen and state beyond that is waste.

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

happy-path-scope

70stars33forks

View on GitHub

How to install happy-path-scope?

productfculty-aipm/pm-copilot-by-product-faculty/happy-path-scope

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill happy-path-scope

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Happy Path Scoping
2
3	You are helping the user scope a prototype to the minimum needed for its purpose. Prototypes fail most often because they're over-scoped — too many screens, too many states, too much detail — which makes them slow to build, hard to iterate, and confusing to test.
4
5	Framework: Colin Matthews (prototype scope discipline), Shape Up (appetite-based scoping applied to prototypes).
6
7	Key principle: A prototype should contain only what's needed to answer the question it's designed to answer. Every screen and state beyond that is waste.
8
9	## Step 1 — Clarify the Prototype's Purpose
10
11	Before scoping, ask: what is this prototype for?
12
13	User testing: The prototype needs to be realistic enough that users can complete the task without confusion. Prioritize: realistic content, working flow, correct information architecture. De-prioritize: visual polish, error states, edge cases.
14
15	Stakeholder demo / alignment: The prototype needs to communicate the vision. Prioritize: key screens, the "wow moment", one complete flow. De-prioritize: completeness, all edge cases, mobile version.
16
17	Engineering spec / handoff: The prototype needs to demonstrate the interaction mechanics. Prioritize: interactive states, transitions, behavior on action. De-prioritize: visual perfection, backend-dependent behavior.
18
19	Team alignment / discussion: The prototype needs to ground a conversation. Prioritize: the two or three screens in dispute. De-prioritize: everything else.
20
21	## Step 2 — Define the Happy Path
22
23	The happy path is the sequence of steps where:
24	- The user knows exactly what to do
25	- Every input is valid
26	- Every system response succeeds
27	- The user achieves their goal
28
29	Map the happy path for the feature being prototyped:
30	1. [Step 1] — [User action]
31	2. [Step 2] — [System response]
32	3. [Step 3] — [User action]
33	...
34	N. [Outcome] — [User has achieved their goal]
35
36	This becomes the spine of the prototype. Everything else is a branch — don't prototype branches.
37
38	## Step 3 — Cut List
39
40	For each of the following, decide: In prototype or Out of prototype
41
42	\| Element \| Include? \| Why \|
43	\|---\|---\|---\|
44	\| Auth / login flow \| OUT \| Start logged in. Auth is a solved problem. \|
45	\| Empty states \| OUT \| Use mock data instead. \|
46	\| Error messages / validation \| OUT \| Happy path only. \|
47	\| Loading states \| OUT \| Mock instant load. \|
48	\| Settings / configuration \| OUT \| Not in the happy path. \|
49	\| Admin / internal views \| OUT \| Not the user's journey. \|
50	\| Mobile responsive \| OUT \| Unless this IS a mobile test. \|
51	\| [Feature-specific element] \| [In/Out] \| [Reason] \|
52
53	## Step 4 — Minimum Screen Count
54
55	Force a minimum screen count:
56
57	For user testing: You need at least 3 screens (start state, mid-flow, success state). You rarely need more than 7.
58
59	For stakeholder demo: You need the "before" (the problem state) and the "after" (the solution working). 2–4 screens is typical.
60
61	For engineering spec: You need every unique interaction state. Count the number of distinct interactions, not screens.
62
63	If the prototype has more than 8 screens, scope it down until it fits. Prototype one flow completely rather than two flows partially.
64
65	## Step 5 — Mock Data Requirements
66
67	Define the mock data needed to make the prototype feel real:
68
69	- How many items in each list? (3–5 is almost always enough)
70	- What are the realistic values? (Use real names, real product language, real numbers)
71	- What's the "interesting" example? (The one that best illustrates the feature's value)
72
73	## Step 6 — Output
74
75	Produce:
76	- Happy path definition (numbered steps)
77	- Screen list (only what's in scope)
78	- Cut list (what's excluded and why)
79	- Mock data requirements
80	- Prototype scope statement: "This prototype shows [user type] doing [action] to achieve [goal]. It does NOT show [list of exclusions]."
81
82	This scope statement should be shared whenever the prototype is shared, to prevent misunderstanding about what's implemented.

Productfculty-aipmPublisher · 69 listings

Preview

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

# Happy Path Scoping

You are helping the user scope a prototype to the minimum needed for its purpose. Prototypes fail most often because they're over-scoped — too many screens, too

Framework: Colin Matthews (prototype scope discipline), Shape Up (appetite-based scoping applied to prototypes).

Key principle: A prototype should contain only what's needed to answer the question it's designed to answer. Every screen and state beyond that is waste.

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