
Stress Test
Break explicit business assumptions—market size, retention, revenue timelines—before investors or the market falsify them.
Overview
stress-test is a journey-wide agent skill that pressure-tests explicit business assumptions before the market does—usable whenever a solo builder needs calibration before committing capital or roadmap.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill stress-testWhat is this skill?
- /em:stress-test command takes a single explicit assumption as input
- Step 1 isolates assumptions into testable statements (not vague "large market" claims)
- Covers market size, customer behavior, revenue model, and hiring velocity assumption types
- Frames stress testing as calibration—not pessimism—for founder optimism bias
- Warns that unanimous team belief is the highest-risk assumption state
Adoption & trust: 1.4k installs on skills.sh; 17.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your model, deck, or roadmap rests on optimistic assumptions nobody has stated precisely enough to disprove.
Who is it for?
Founders preparing validation, fundraising, or annual planning who want a disciplined assumption break-down without hiring a strategy consultant.
Skip if: Purely technical debugging or code review tasks unrelated to business model claims.
When should I use this skill?
User runs /em:stress-test with an explicit business assumption (market size, retention, revenue, hiring, moat).
What do I get? / Deliverables
You end with isolated, testable assumptions and stress-tested failure modes so you can adjust scope, pricing, or timeline before real losses.
- Isolated assumption statement
- Stress-test findings and failure modes
- Calibration notes for model or plan updates
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Stress-test a TAM figure before you spend months building for a niche that cannot pay.
Challenge "$2M ARR by December" assumptions before locking the MVP scope and hire plan.
Pressure-test willingness-to-pay and churn assumptions behind your pricing page.
Re-run stress tests when dashboard retention looks good but expansion revenue assumptions lag.
Sanity-check launch volume and conversion assumptions tied to a fixed ship date.
How it compares
Assumption calibration workflow—not a financial modeling spreadsheet or generic brainstorming without falsification steps.
Common Questions / FAQ
Who is stress-test for?
Solo and indie builders who own business models, revenue plans, or investor narratives and need to challenge consensus numbers before betting the company.
When should I use stress-test?
In Idea when sizing opportunity, in Validate before locking scope or pricing, in Ship before launch commitments, or in Grow when retention or expansion assumptions look too smooth—any time you can name the assumption in one sentence.
Is stress-test safe to install?
It is analytical prose invoked via /em:stress-test; review the Security Audits panel on this Prism page before adding third-party skill packs to your agent.
SKILL.md
READMESKILL.md - Stress Test
# /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 t