stress-test

Overview of stress-test skill

What stress-test is for

The stress-test skill is a business assumption testing workflow for Claude-style executive mentoring. It helps you take a strategic claim—such as “enterprise buyers will accept a six-month pilot,” “our TAM is €2.3B,” or “we can reach $2M ARR by December”—and pressure-test it before you commit capital, hiring, roadmap, or investor messaging around it.

Use it when the risk is not that your plan is incomplete, but that one attractive assumption is carrying too much weight.

Best-fit users and decisions

This stress-test skill is best for founders, executives, product leaders, finance teams, strategy operators, and advisors who need sharper downside analysis before a major decision. It fits work such as fundraising plans, go-to-market strategy, pricing changes, market-entry bets, retention forecasts, hiring ramps, moat claims, and board narratives.

It is especially useful as stress-test for Strategic Planning because it converts optimism-heavy planning assumptions into explicit, falsifiable claims that can be challenged.

What makes it different

A generic prompt may ask an AI to “find risks.” The stress-test workflow is narrower: isolate the assumption, make it concrete, look for counter-evidence, and expose where the plan breaks. That focus matters because vague assumptions are hard to falsify. “The market is large” produces weak analysis; “German SMEs will spend €X annually on B2B spend management software within 18 months” gives the model something testable.

How to Use stress-test skill

stress-test install and repository context

Install from the GitHub skill repository using your skill manager, for example:

npx skills add alirezarezvani/claude-skills --skill stress-test

The skill lives at:

c-level-advisor/executive-mentor/skills/stress-test

This repository entry appears to be self-contained: the important file to inspect first is SKILL.md. There are no visible supporting rules/, resources/, references/, or scripts in the provided tree, so adoption depends mainly on whether the embedded method matches your planning workflow.

Inputs the skill needs

Call the skill with a single assumption, not a broad topic:

/em:stress-test <assumption>

Weak input:

/em:stress-test our enterprise strategy

Better input:

/em:stress-test enterprise buyers in regulated industries will tolerate a six-month unpaid pilot before procurement approval

Strong input:

/em:stress-test 40% of qualified enterprise prospects in US healthcare will accept a six-month unpaid pilot, and at least 25% of those pilots will convert to $120k ACV contracts within one quarter

The stronger version gives the model a segment, behavior, timing, conversion expectation, and commercial consequence. That makes the output more useful because the skill can challenge each component instead of producing generic strategy risks.

Suggested stress-test usage workflow

Use this stress-test guide before the decision is locked, not after the plan has already become internal doctrine.

1. Identify the plan that depends on optimism: revenue forecast, market entry, hiring model, retention target, pricing change, funding timeline, or moat claim.
2. Extract the one assumption that would damage the plan most if false.
3. Rewrite it as a measurable claim with customer segment, geography, time horizon, volume, price, conversion rate, or cost.
4. Run /em:stress-test on that assumption.
5. Ask follow-ups: “What evidence would disconfirm this fastest?”, “What leading indicators should we watch?”, and “What lower-risk version of the plan survives if this assumption is wrong?”

This works well in executive review because it separates confidence from evidence.

Files to read before relying on it

Start with SKILL.md. Pay attention to the sections on why assumptions fail, the stress-test methodology, isolating the assumption, and finding counter-evidence. Because the visible skill has no extra reference pack or automation, you should not expect it to fetch market data or validate numbers independently. Treat it as a structured reasoning aid and bring your own facts, benchmarks, customer evidence, CRM data, financial model assumptions, or investor constraints.

stress-test skill FAQ

Is stress-test only for startups?

No. The examples are founder-friendly, but the pattern applies to any organization making a bet under uncertainty. Corporate strategy teams can use it for market expansion, procurement assumptions, sales capacity plans, transformation programs, and product portfolio decisions. The core requirement is a decision that depends on a testable business assumption.

How is this better than asking Claude for risks?

Ordinary risk prompts often produce broad lists: competition, budget, timing, execution, adoption. The stress-test skill pushes you to name the load-bearing assumption and attack it directly. That makes the analysis more decision-relevant. Instead of “sales may be hard,” you get pressure on the specific belief that “mid-market buyers will close in 45 days at $30k ACV without security review.”

When should I not use this skill?

Do not use it as a substitute for market research, legal advice, financial audit, customer discovery, or statistical forecasting. It also performs poorly if you provide a slogan instead of an assumption. If your question is exploratory—“What business should we build?”—start with discovery or strategy framing first. Use stress-test when you already have a claim that deserves scrutiny.

Is stress-test beginner-friendly?

Yes, if you can write the assumption clearly. Beginners often get value by asking the model to first help turn a vague plan into several candidate assumptions, then choosing the riskiest one for /em:stress-test. More experienced operators should provide numeric thresholds, known evidence, constraints, and decision stakes from the start.

How to Improve stress-test skill

Make the assumption more falsifiable

The most important way to improve stress-test output is to remove ambiguity. Include who, what, where, when, how much, and what outcome matters.

Instead of:

customers will love the product

Use:

at least 30% of finance teams at 200-1000 employee SaaS companies will switch from spreadsheets to our forecasting tool within 90 days if priced below $500/month

That gives the skill clear surfaces to challenge: segment, urgency, switching behavior, timeframe, and pricing.

Add evidence and constraints up front

The stress-test skill can reason better when it knows what evidence already exists. Include customer interviews, win/loss notes, pipeline data, conversion rates, churn cohorts, sales cycle history, competitive alternatives, budget cycles, procurement friction, or investor milestones.

A stronger prompt might add:

Known evidence: 12 discovery calls, 3 verbal pilots, no signed LOIs, average procurement cycle 4-7 months, current runway 9 months.

This prevents the output from treating all possibilities as equally likely.

Watch for common failure modes

The main failure mode is stress testing an assumption that is too broad, too political, or too detached from the decision. Another common issue is asking for validation rather than challenge. If you want useful output, do not frame the prompt as “prove this plan works.” Frame it as “break this assumption before we depend on it.”

Also avoid bundling many assumptions into one command. If your plan depends on market size, willingness to pay, sales cycle, and retention, test each separately.

Iterate after the first stress-test

After the first output, ask for decision-grade refinement:

• “Rank the failure points by probability and severity.”
• “What evidence would change your view fastest?”
• “Design a two-week test for the riskiest assumption.”
• “Rewrite the plan so it still works if this assumption is 50% wrong.”
• “What board or investor question would expose this weakness?”

This turns stress-test from a one-off critique into a practical planning loop: assumption, challenge, evidence, revision, and decision.