pmf-validate

Name: pmf-validate
Author: gnurio

2installs4forks

How to install pmf-validate?

gnurio/pmf-plugin/pmf-validate

$npx -y skills add gnurio/pmf-plugin --skill pmf-validate

Installs into the current project.

Summary

Use this skill after /pmf-research-synthesis has identified the riskiest PMF dimension. Takes that dimension (or any business idea/strategy) and runs a structured assumption extraction, mapping, and experiment design sequence. Triggers include: 'validate my riskiest dimension', '

Files · 1

View on GitHub

SKILL.md

1	# PMF Validate
2
3	## Purpose
4
5	Surface and test the riskiest assumptions inside your riskiest PMF dimension — before committing time, money, or credibility. Run this after `/pmf-research-synthesis` has told you which dimension to focus on.
6
7	Feed in your riskiest dimension (e.g. "Competitive Advantage — Anti-Slop Positioning") or any specific strategy, and this skill will extract the 9 specific assumptions that could prove it wrong, help you map them by importance vs. evidence, and design a structured experiment brief for the one that matters most.
8
9	---
10
11	## Core Principles
12
13	These rules apply across all three phases without exception.
14
15	- Never say "hypothesis" or "hypotheses" — always say "assumption" or "assumption to test"
16	- Every assumption must start with "I believe..." or "We believe..."
17	- Desirability = user needs, problem severity, perceived value, solution fit only. Never include pricing, dollar amounts, willingness to pay, or any financial assumptions here
18	- Viability = all financial assumptions: pricing, willingness to pay, revenue, margins, unit economics, business model sustainability
19	- Feasibility = operational, technical, or organizational delivery assumptions
20	- Tone: calm, coaching-oriented, no exclamation points, executive-level precision
21	- Never ask clarifying questions before generating — work with whatever is provided and make reasonable inferences
22	- Never use motivational or hype language
23
24	---
25
26	## Flow Overview
27
28	Run phases in sequence. Do not skip ahead. After each phase, ask if the user wants to continue to the next.
29
30	Phase 1: Extract → Surface DVF assumptions from the idea
31	Phase 2: Map → Critique the user's assumption map
32	Phase 3: Test → Design a structured experiment brief for the riskiest assumption
33
34	---
35
36	## Phase 1: Extract Assumptions
37
38	### Trigger
39	User provides a PMF dimension, business idea, strategy, or initiative they want to pressure-test.
40
41	### Behavior
42	Before generating assumptions, silently analyze:
43	- What would have to go wrong for this dimension/idea to fail?
44	- Where does the biggest uncertainty exist about user behavior, revenue, or execution?
45	- Which beliefs is the team implicitly relying on to move forward?
46
47	Convert those failure points into assumptions starting with "I believe..." or "We believe..." Do not show this analysis. Output only the assumption tables.
48
49	Work with whatever is provided. If the input is vague, make reasonable inferences and generate assumptions anyway. Never ask clarifying questions before generating.
50
51	Output exactly 3 assumptions per category in markdown table format.
52
53	### Output Format
54
55	```
56	## Desirability
57	\| Category \| Assumption \| Rationale \|
58	\|----------\|------------\|-----------\|
59	\| Desirable \| I believe [assumption] \| Why this matters and what breaks if it is wrong... \|
60
61	## Viability
62	\| Category \| Assumption \| Rationale \|
63	\|----------\|------------\|-----------\|
64	\| Viable \| I believe [assumption] \| Why this matters and what breaks if it is wrong... \|
65
66	## Feasibility
67	\| Category \| Assumption \| Rationale \|
68	\|----------\|------------\|-----------\|
69	\| Feasible \| I believe [assumption] \| Why this matters and what breaks if it is wrong... \|
70	```
71
72	### Rules
73	- Output tables directly — no conversational preamble or postamble
74	- 3 assumptions per category, no more, no less
75	- Each assumption must start with "I believe..."
76	- Never put financial assumptions in Desirability
77	- Never put user-need assumptions in Viability
78	- Assumptions must describe something that could prove the idea wrong if tested
79	- Prefer assumptions about observable behavior rather than opinions
80	- Avoid assumptions about total market size, industry growth, or macro trends unless they directly affect early adoption or revenue
81	- Each assumption should represent a distinct risk — do not repeat the same idea across categories
82	- Do not explain the assumptions before or after the tables
83
84	### DVF Tension Check
85	After outputting the assumption tables, identify the single most important tension between the DVF categories. Examples of tensions to surface:
86
87	- A Desirability assumption that depends on user behavior that conflicts with a Viability assumption about willingness to pay
88	- A Feasibility constraint that limits the value promised by a Desirability assumption
89	- A Viability assumption about profitability that relies on user behavior that may not occur
90
91	Each tension should be 1-2 sentences and re

People who liked this also viewed

6 picks

Type

pmf-validate

2installs4forks

View on GitHub

How to install pmf-validate?

gnurio/pmf-plugin/pmf-validate

$npx -y skills add gnurio/pmf-plugin --skill pmf-validate

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PMF Validate
2
3	## Purpose
4
5	Surface and test the riskiest assumptions inside your riskiest PMF dimension — before committing time, money, or credibility. Run this after `/pmf-research-synthesis` has told you which dimension to focus on.
6
7	Feed in your riskiest dimension (e.g. "Competitive Advantage — Anti-Slop Positioning") or any specific strategy, and this skill will extract the 9 specific assumptions that could prove it wrong, help you map them by importance vs. evidence, and design a structured experiment brief for the one that matters most.
8
9	---
10
11	## Core Principles
12
13	These rules apply across all three phases without exception.
14
15	- Never say "hypothesis" or "hypotheses" — always say "assumption" or "assumption to test"
16	- Every assumption must start with "I believe..." or "We believe..."
17	- Desirability = user needs, problem severity, perceived value, solution fit only. Never include pricing, dollar amounts, willingness to pay, or any financial assumptions here
18	- Viability = all financial assumptions: pricing, willingness to pay, revenue, margins, unit economics, business model sustainability
19	- Feasibility = operational, technical, or organizational delivery assumptions
20	- Tone: calm, coaching-oriented, no exclamation points, executive-level precision
21	- Never ask clarifying questions before generating — work with whatever is provided and make reasonable inferences
22	- Never use motivational or hype language
23
24	---
25
26	## Flow Overview
27
28	Run phases in sequence. Do not skip ahead. After each phase, ask if the user wants to continue to the next.
29
30	Phase 1: Extract → Surface DVF assumptions from the idea
31	Phase 2: Map → Critique the user's assumption map
32	Phase 3: Test → Design a structured experiment brief for the riskiest assumption
33
34	---
35
36	## Phase 1: Extract Assumptions
37
38	### Trigger
39	User provides a PMF dimension, business idea, strategy, or initiative they want to pressure-test.
40
41	### Behavior
42	Before generating assumptions, silently analyze:
43	- What would have to go wrong for this dimension/idea to fail?
44	- Where does the biggest uncertainty exist about user behavior, revenue, or execution?
45	- Which beliefs is the team implicitly relying on to move forward?
46
47	Convert those failure points into assumptions starting with "I believe..." or "We believe..." Do not show this analysis. Output only the assumption tables.
48
49	Work with whatever is provided. If the input is vague, make reasonable inferences and generate assumptions anyway. Never ask clarifying questions before generating.
50
51	Output exactly 3 assumptions per category in markdown table format.
52
53	### Output Format
54
55	```
56	## Desirability
57	\| Category \| Assumption \| Rationale \|
58	\|----------\|------------\|-----------\|
59	\| Desirable \| I believe [assumption] \| Why this matters and what breaks if it is wrong... \|
60
61	## Viability
62	\| Category \| Assumption \| Rationale \|
63	\|----------\|------------\|-----------\|
64	\| Viable \| I believe [assumption] \| Why this matters and what breaks if it is wrong... \|
65
66	## Feasibility
67	\| Category \| Assumption \| Rationale \|
68	\|----------\|------------\|-----------\|
69	\| Feasible \| I believe [assumption] \| Why this matters and what breaks if it is wrong... \|
70	```
71
72	### Rules
73	- Output tables directly — no conversational preamble or postamble
74	- 3 assumptions per category, no more, no less
75	- Each assumption must start with "I believe..."
76	- Never put financial assumptions in Desirability
77	- Never put user-need assumptions in Viability
78	- Assumptions must describe something that could prove the idea wrong if tested
79	- Prefer assumptions about observable behavior rather than opinions
80	- Avoid assumptions about total market size, industry growth, or macro trends unless they directly affect early adoption or revenue
81	- Each assumption should represent a distinct risk — do not repeat the same idea across categories
82	- Do not explain the assumptions before or after the tables
83
84	### DVF Tension Check
85	After outputting the assumption tables, identify the single most important tension between the DVF categories. Examples of tensions to surface:
86
87	- A Desirability assumption that depends on user behavior that conflicts with a Viability assumption about willingness to pay
88	- A Feasibility constraint that limits the value promised by a Desirability assumption
89	- A Viability assumption about profitability that relies on user behavior that may not occur
90
91	Each tension should be 1-2 sentences and re

People who liked this also viewed

6 picks

Type