New: Earn 20% as an AgentAlley affiliate. Share your link and earn on every sale you refer. Join now New: Earn 20% as an affiliate. Join now

Em:stress-test — Business Assumption Stress Testing

by alirezarezvani · MIT license · ★ 26,349 on GitHub · updated Aug 30

/em:stress-test — Business Assumption Stress Testing cover

/em:stress-test — Business assumption stress testing. Use before betting on a plan whose core assumptions are unvalidated — e.g.

---
name: "stress-test"
description: "/em:stress-test — Business assumption stress testing. Use before betting on a plan whose core assumptions are unvalidated — e.g. stress-testing 'enterprise buyers will tolerate a 6-month pilot' or a hockey-stick revenue model."
---

# /em:stress-test — Business Assumption Stress Testing

**Command:** `/em:stress-test <assumption>`

Take any business assumption and break it before the market does. Revenue projections. Market size. Competitive moat. Hiring velocity. Customer retention.

---

## Why Most Assumptions Are Wrong

Founders are optimists by nature. That's a feature — you need optimism to start something from nothing. But it becomes a liability when assumptions in business models get inflated by the same optimism that got you started.

**The most dangerous assumptions are the ones everyone agrees on.**

Overview

Take any business assumption and break it before the market does. Revenue projections. Market size. Competitive moat. Hiring velocity. Customer retention.

Manual install (npx, ZIP)
Claude Codenpx skills add alirezarezvani/claude-skills --skill stress-test -g -a claude-code
Claude Code (manual)mkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/alirezarezvani/claude-skills/tar.gz/19392f7a0826 \ | tar -xz -C ~/.claude/skills --strip-components=4 claude-skills-19392f7a0826/c-level-advisor/executive-mentor/skills/stress-test
Windows (PowerShell)New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/f6028b415741aaf97c42/stress-test.zip" -OutFile "$env:TEMP\stress-test.zip"; Expand-Archive "$env:TEMP\stress-test.zip" -DestinationPath "$HOME\.claude\skills" -Force
Claude.ai / desktopDownload the ZIP and upload it under Settings → Capabilities → Skills.
Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

  • SKILL.md7.7 KB
Read the files here
alirezarezvani/19392f71 file
SKILL.md
Show the full text205 lines

/em:stress-test — Business Assumption Stress Testing

Command: /em:stress-test <assumption>

Take any business assumption and break it before the market does. Revenue projections. Market size. Competitive moat. Hiring velocity. Customer retention.


Why Most Assumptions Are Wrong

Founders are optimists by nature. That's a feature — you need optimism to start something from nothing. But it becomes a liability when assumptions in business models get inflated by the same optimism that got you started.

The most dangerous assumptions are the ones everyone agrees on.

When the whole team believes the $50M market is real, when every investor call goes well so you assume the round will close, when your model shows $2M ARR by December and nobody questions it — that's when you're most exposed.

Stress testing isn't pessimism. It's calibration.


The Stress-Test Methodology

Step 1: Isolate the Assumption

State it explicitly. Not "our market is large" but "the total addressable market for B2B spend management software in German SMEs is €2.3B."

The more specific the assumption, the more testable it is. Vague assumptions are unfalsifiable — and therefore useless.

Common assumption types:

  • Market size — TAM, SAM, SOM; growth rate; customer segments
  • Customer behavior — willingness to pay, churn, expansion, referrals
  • Revenue model — conversion rates, deal size, sales cycle, CAC
  • Competitive position — moat durability, competitor response speed, switching cost
  • Execution — team velocity, hire timeline, product timeline, operational scaling
  • Macro — regulatory environment, economic conditions, technology availability
Step 2: Find the Counter-Evidence

For every assumption, actively search for evidence that it's wrong.

Ask:

  • Who has tried this and failed?
  • What data contradicts this assumption?
  • What does the bear case look like?
  • If a smart skeptic was looking at this, what would they point to?
  • What's the base rate for assumptions like this?

Sources of counter-evidence:

  • Comparable companies that failed in adjacent markets
  • Customer churn data from similar businesses
  • Historical accuracy of similar forecasts
  • Industry reports with conflicting data
  • What competitors who tried this found

The goal isn't to find a reason to stop — it's to surface what you don't know.

Step 3: Model the Downside

Most plans model the base case and the upside. Stress testing means modeling the downside explicitly.

For quantitative assumptions (revenue, growth, conversion):

Scenario Assumption Value Probability Impact
Base case [Original value] ?
Bear case -30% ?
Stress case -50% ?
Catastrophic -80% ?

Key question at each level: Does the business survive? Does the plan make sense?

For qualitative assumptions (moat, product-market fit, team capability):

  • What's the earliest signal this assumption is wrong?
  • How long would it take you to notice?
  • What happens between when it breaks and when you detect it?
Step 4: Calculate Sensitivity

Some assumptions matter more than others. Sensitivity analysis answers: if this one assumption changes, how much does the outcome change?

Example:

  • If CAC doubles, how does that change runway?
  • If churn goes from 5% to 10%, how does that change NRR in 24 months?
  • If the deal cycle is 6 months instead of 3, how does that affect Q3 revenue?

High sensitivity = the assumption is a key lever. Wrong = big problem.

Step 5: Propose the Hedge

For every high-risk assumption, there should be a hedge:

  • Validation hedge — test it before betting on it (pilot, customer conversation, small experiment)
  • Contingency hedge — if it's wrong, what's plan B?
  • Early warning hedge — what's the leading indicator that would tell you it's breaking before it's too late to act?

Stress Test Patterns by Assumption Type

Revenue Projections

Common failures:

  • Bottom-up model assumes 100% of pipeline converts
  • Doesn't account for deal slippage, churn, seasonality
  • New channel assumed to work before tested at scale

Stress questions:

  • What's your actual historical win rate on pipeline?
  • If your top 3 deals slip to next quarter, what happens to the number?
  • What's the model look like if your new sales rep takes 4 months to ramp, not 2?
  • If expansion revenue doesn't materialize, what's the growth rate?

Test: Build the revenue model from historical win rates, not hoped-for ones.

Market Size

Common failures:

  • TAM calculated top-down from industry reports without bottoms-up validation
  • Conflating total market with serviceable market
  • Assuming 100% of SAM is reachable

Stress questions:

  • How many companies in your ICP actually exist and can you name them?
  • What's your serviceable obtainable market in year 1-3?
  • What percentage of your ICP is currently spending on any solution to this problem?
  • What does "winning" look like and what market share does that require?

Test: Build a list of target accounts. Count them. Multiply by ACV. That's your SAM.

Competitive Moat

Common failures:

  • Moat is technology advantage that can be built in 6 months
  • Network effects that haven't yet materialized
  • Data advantage that requires scale you don't have

Stress questions:

  • If a well-funded competitor copied your best feature in 90 days, what do customers do?
  • What's your retention rate among customers who have tried alternatives?
  • Is the moat real today or theoretical at scale?
  • What would it cost a competitor to reach feature parity?

Test: Ask churned customers why they left and whether a competitor could have kept them.

Hiring Plan

Common failures:

  • Time-to-hire assumes standard recruiting cycle, not current market
  • Ramp time not modeled (3-6 months before full productivity)
  • Key hire dependency: plan only works if specific person is hired

Stress questions:

  • What happens if the VP Sales hire takes 5 months, not 2?
  • What does execution look like if you only hire 70% of planned headcount?
  • Which single person, if they left tomorrow, would most damage the plan?
  • Is the plan achievable with current team if hiring freezes?

Test: Model the plan with 0 net new hires. What still works?

Competitive Response

Common failures:

  • Assumes incumbents won't respond (they will if you're winning)
  • Underestimates speed of response
  • Doesn't model resource asymmetry

Stress questions:

  • If the market leader copies your product in 6 months, how does pricing change?
  • What's your response if a competitor raises $30M to attack your space?
  • Which of your customers have vendor relationships with your competitors?

The Stress Test Output

ASSUMPTION: [Exact statement]
SOURCE: [Where this came from — model, investor pitch, team gut feel]

COUNTER-EVIDENCE
• [Specific evidence that challenges this assumption]
• [Comparable failure case]
• [Data point that contradicts the assumption]

DOWNSIDE MODEL
• Bear case (-30%): [Impact on plan]
• Stress case (-50%): [Impact on plan]
• Catastrophic (-80%): [Impact on plan — does the business survive?]

SENSITIVITY
This assumption has [HIGH / MEDIUM / LOW] sensitivity.
A 10% change → [X] change in outcome.

HEDGE
• Validation: [How to test this before betting on it]
• Contingency: [Plan B if it's wrong]
• Early warning: [Leading indicator to watch — and at what threshold to act]
1---
2name: "stress-test"
3description: "/em:stress-test — Business assumption stress testing. Use before betting on a plan whose core assumptions are unvalidated — e.g. stress-testing 'enterprise buyers will tolerate a 6-month pilot' or a hockey-stick revenue model."
4---
5 
6# /em:stress-test — Business Assumption Stress Testing
7 
8**Command:** `/em:stress-test <assumption>`
9 
10Take any business assumption and break it before the market does. Revenue projections. Market size. Competitive moat. Hiring velocity. Customer retention.
11 
12---
13 
14## Why Most Assumptions Are Wrong
15 
16Founders are optimists by nature. That's a feature — you need optimism to start something from nothing. But it becomes a liability when assumptions in business models get inflated by the same optimism that got you started.
17 
18**The most dangerous assumptions are the ones everyone agrees on.**
19 
20When the whole team believes the $50M market is real, when every investor call goes well so you assume the round will close, when your model shows $2M ARR by December and nobody questions it — that's when you're most exposed.
21 
22Stress testing isn't pessimism. It's calibration.
23 
24---
25 
26## The Stress-Test Methodology
27 
28### Step 1: Isolate the Assumption
29 
30State it explicitly. Not "our market is large" but "the total addressable market for B2B spend management software in German SMEs is €2.3B."
31 
32The more specific the assumption, the more testable it is. Vague assumptions are unfalsifiable — and therefore useless.
33 
34**Common assumption types:**
35- **Market size** — TAM, SAM, SOM; growth rate; customer segments
36- **Customer behavior** — willingness to pay, churn, expansion, referrals
37- **Revenue model** — conversion rates, deal size, sales cycle, CAC
38- **Competitive position** — moat durability, competitor response speed, switching cost
39- **Execution** — team velocity, hire timeline, product timeline, operational scaling
40- **Macro** — regulatory environment, economic conditions, technology availability
41 
42### Step 2: Find the Counter-Evidence
43 
44For every assumption, actively search for evidence that it's wrong.
45 
46Ask:
47- Who has tried this and failed?
48- What data contradicts this assumption?
49- What does the bear case look like?
50- If a smart skeptic was looking at this, what would they point to?
51- What's the base rate for assumptions like this?
52 
53**Sources of counter-evidence:**
54- Comparable companies that failed in adjacent markets
55- Customer churn data from similar businesses
56- Historical accuracy of similar forecasts
57- Industry reports with conflicting data
58- What competitors who tried this found
59 
60The goal isn't to find a reason to stop — it's to surface what you don't know.
61 
62### Step 3: Model the Downside
63 
64Most plans model the base case and the upside. Stress testing means modeling the downside explicitly.
65 
66**For quantitative assumptions (revenue, growth, conversion):**
67 
68| Scenario | Assumption Value | Probability | Impact |
69|----------|-----------------|-------------|--------|
70| Base case | [Original value] | ? | |
71| Bear case | -30% | ? | |
72| Stress case | -50% | ? | |
73| Catastrophic | -80% | ? | |
74 
75Key question at each level: **Does the business survive? Does the plan make sense?**
76 
77**For qualitative assumptions (moat, product-market fit, team capability):**
78 
79- What's the earliest signal this assumption is wrong?
80- How long would it take you to notice?
81- What happens between when it breaks and when you detect it?
82 
83### Step 4: Calculate Sensitivity
84 
85Some assumptions matter more than others. Sensitivity analysis answers: **if this one assumption changes, how much does the outcome change?**
86 
87Example:
88- If CAC doubles, how does that change runway?
89- If churn goes from 5% to 10%, how does that change NRR in 24 months?
90- If the deal cycle is 6 months instead of 3, how does that affect Q3 revenue?
91 
92High sensitivity = the assumption is a key lever. Wrong = big problem.
93 
94### Step 5: Propose the Hedge
95 
96For every high-risk assumption, there should be a hedge:
97 
98- **Validation hedge** — test it before betting on it (pilot, customer conversation, small experiment)
99- **Contingency hedge** — if it's wrong, what's plan B?
100- **Early warning hedge** — what's the leading indicator that would tell you it's breaking before it's too late to act?
101 
102---
103 
104## Stress Test Patterns by Assumption Type
105 
106### Revenue Projections
107 
108**Common failures:**
109- Bottom-up model assumes 100% of pipeline converts
110- Doesn't account for deal slippage, churn, seasonality
111- New channel assumed to work before tested at scale
112 
113**Stress questions:**
114- What's your actual historical win rate on pipeline?
115- If your top 3 deals slip to next quarter, what happens to the number?
116- What's the model look like if your new sales rep takes 4 months to ramp, not 2?
117- If expansion revenue doesn't materialize, what's the growth rate?
118 
119**Test:** Build the revenue model from historical win rates, not hoped-for ones.
120 
121### Market Size
122 
123**Common failures:**
124- TAM calculated top-down from industry reports without bottoms-up validation
125- Conflating total market with serviceable market
126- Assuming 100% of SAM is reachable
127 
128**Stress questions:**
129- How many companies in your ICP actually exist and can you name them?
130- What's your serviceable obtainable market in year 1-3?
131- What percentage of your ICP is currently spending on any solution to this problem?
132- What does "winning" look like and what market share does that require?
133 
134**Test:** Build a list of target accounts. Count them. Multiply by ACV. That's your SAM.
135 
136### Competitive Moat
137 
138**Common failures:**
139- Moat is technology advantage that can be built in 6 months
140- Network effects that haven't yet materialized
141- Data advantage that requires scale you don't have
142 
143**Stress questions:**
144- If a well-funded competitor copied your best feature in 90 days, what do customers do?
145- What's your retention rate among customers who have tried alternatives?
146- Is the moat real today or theoretical at scale?
147- What would it cost a competitor to reach feature parity?
148 
149**Test:** Ask churned customers why they left and whether a competitor could have kept them.
150 
151### Hiring Plan
152 
153**Common failures:**
154- Time-to-hire assumes standard recruiting cycle, not current market
155- Ramp time not modeled (3-6 months before full productivity)
156- Key hire dependency: plan only works if specific person is hired
157 
158**Stress questions:**
159- What happens if the VP Sales hire takes 5 months, not 2?
160- What does execution look like if you only hire 70% of planned headcount?
161- Which single person, if they left tomorrow, would most damage the plan?
162- Is the plan achievable with current team if hiring freezes?
163 
164**Test:** Model the plan with 0 net new hires. What still works?
165 
166### Competitive Response
167 
168**Common failures:**
169- Assumes incumbents won't respond (they will if you're winning)
170- Underestimates speed of response
171- Doesn't model resource asymmetry
172 
173**Stress questions:**
174- If the market leader copies your product in 6 months, how does pricing change?
175- What's your response if a competitor raises $30M to attack your space?
176- Which of your customers have vendor relationships with your competitors?
177 
178---
179 
180## The Stress Test Output
181 
182```
183ASSUMPTION: [Exact statement]
184SOURCE: [Where this came from — model, investor pitch, team gut feel]
185 
186COUNTER-EVIDENCE
187• [Specific evidence that challenges this assumption]
188• [Comparable failure case]
189• [Data point that contradicts the assumption]
190 
191DOWNSIDE MODEL
192• Bear case (-30%): [Impact on plan]
193• Stress case (-50%): [Impact on plan]
194• Catastrophic (-80%): [Impact on plan — does the business survive?]
195 
196SENSITIVITY
197This assumption has [HIGH / MEDIUM / LOW] sensitivity.
198A 10% change → [X] change in outcome.
199 
200HEDGE
201• Validation: [How to test this before betting on it]
202• Contingency: [Plan B if it's wrong]
203• Early warning: [Leading indicator to watch — and at what threshold to act]
204```
205 
View all files on GitHub →

Details

Updated
Aug 30, 2026
License
MIT
Stars on the repo
★ 26,349
Checked
Source
alirezarezvani/claude-skills ↗
Creator
alirezarezvani · 363 listings
View creator

Similar skills

See all →
Skill29 production-ready scripts for iOS app testing, buildingIos simulator skillconorluddy/ios-simulator-skill · by conorluddy29 production-ready scripts for iOS app testing, building, and automation. Provides semantic UI navigation, build automation, accessibility testing, and simulator lifecycle management. Optimized for AI agents with minimal token output.★ 1.3k GitHub starsSkillMoAI unified orchestrator for autonomous developmentmodu-ai/moai-adk · by modu-aiMoAI unified orchestrator for autonomous development. Routes natural language or subcommands (plan, run, sync, project, fix, loop, mx, feedback, review, clean, codemaps, gate, e2e, harness, goal, gtd, todo) to specialized agents.★ 1.2k GitHub starsSkillWrite Android unit, Compose UI, and Hilt-integrated testsAndroid Testing StandardsHoangNguyen0403/agent-skills-standard · by HoangNguyen0403Write Android unit, Compose UI, and Hilt-integrated tests. Use when designing test behavior with MockK or coroutine test utilities; defer database/WorkManager-specific recipes to the owning feature skill.★ 569 GitHub starsSkillImplementing any feature or bugfixTest-Driven Development (TDD)obra/superpowers · by obraUse when implementing any feature or bugfix, before writing implementation code★ 290k GitHub starsSkillToolkit for interacting with and testing local webWebapp testinganthropics/skills · by anthropicsToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.★ 178k GitHub starsPromptGuide to fixing bugs using a test-first approachTest first bug fixing approachf/prompts.chat · by Ilker UlusoyGuide to fixing bugs using a test-first approach, ensuring code reliability through systematic testing and implementation.New listing

More from alirezarezvani

SkillResume a paused experiment/ar:ar-resume — Resume Experimentalirezarezvani/claude-skills · by alirezarezvaniResume a paused experiment. Checkout the experiment branch, read results history, continue iterating. Use when the user runs /ar:ar-resume or asks to pick up a previously started autoresearch experiment.★ 26.3k GitHub starsSkillShow experiment dashboard with results, active loops/ar:ar-status — Experiment Dashboardalirezarezvani/claude-skills · by alirezarezvaniShow experiment dashboard with results, active loops, and progress. Use when the user runs /ar:ar-status or asks how an autoresearch experiment is going.★ 26.3k GitHub starsSkillStart an autonomous experiment loop with user-selected/ar:loop — Autonomous Experiment Loopalirezarezvani/claude-skills · by alirezarezvaniStart an autonomous experiment loop with user-selected interval (10min, 1h, daily, weekly, monthly). Uses CronCreate for scheduling. Use when the user runs /ar:loop or asks to run an autoresearch experiment continuously on a schedule.★ 26.3k GitHub starsSkillRun a single experiment iteration/ar:run — Single Experiment Iterationalirezarezvani/claude-skills · by alirezarezvaniRun a single experiment iteration. Edit the target file, evaluate, keep or discard. Use when the user runs /ar:run or asks for one manual autoresearch iteration.★ 26.3k GitHub starsSkillSet up a new autoresearch experiment interactively/ar:setup — Create New Experimentalirezarezvani/claude-skills · by alirezarezvaniSet up a new autoresearch experiment interactively. Collects domain, target file, eval command, metric, direction, and evaluator. Use when the user runs /ar:setup or asks to start optimizing a file with the autoresearch loop.★ 26.3k GitHub starsSkill/cs:boardroom <brief/cs:boardroom — Multi-Role Boardroom Deliberationalirezarezvani/claude-skills · by alirezarezvani/cs:boardroom <brief> — 6-phase multi-role deliberation across the C-suite with Phase 2 isolation, critic pre-screen, and synthesis. Outputs a board memo. Use when a decision spans multiple executive domains — e.g. a pricing change touching finance, positioning, and product, or a raise-vs-cut runway call.★ 26.3k GitHub stars