Pressure Test
Stress-tests a feature idea against constraints, users, and your existing system in one pass. Verdict: kill or proceed with conditions. No building required.
How It Works
- Plan, idea, or decision: A spec, PR, strategy memo — anything you're attached to
- Premortem: It failed 6 months out — name the false assumption that killed it
- Blind spots: Cynical competitor view — how they'd exploit the weaknesses
- Risk ranking: Top 3 risks scored likelihood × impact, each with a contingency
- Verdict + top 3 changes: Survivability call · load-bearing assumption · fix before proceeding
Invocation Triggers
/pressure-testpressure testvalidate ideashould I build thisis this worth buildingUse Cases
- Kill a bad feature idea before writing a single line of code
- Stress-test a proposed addition against your existing system constraints
- Get a structured kill/proceed verdict before writing a PRD
The Problem
You have an idea. It feels right. You build it. Six hours later you realize it doesn't fit the system, solves a problem no one actually has, or creates three new ones. The time to find this out is before the first commit — not after the first PR review.
What It Does
- 1Define the idea precisely
One sentence: who, what, why now. If you can't write this sentence, the idea isn't ready. This is a hard gate — a vague idea produces a useless verdict.
- 2Constraints check
Does it fit your stack, your scale, your existing data model, your deployment constraints? List every constraint violation explicitly.
- 3User evidence check
Who specifically wants this — name them. What do they do instead today? "Someone would want this" is not a user. If you can't name a person and describe their current workaround, this check fails.
- 4Integration risk check
What breaks if you add this? What does it conflict with? What new dependencies does it introduce? Be specific — "it might cause issues" is not an integration risk.
- 5Kill / proceed verdict
Explicit reasoning for each check. Kill if any check fails without a clear mitigation. Proceed with conditions if all checks pass — list the conditions. The kill verdict is the success case.
What You Get / What It Doesn't Do
- Kill / Proceed verdict with explicit reasons for each check
- Constraint violations listed with severity
- Specific user evidence (or documented lack thereof)
- Integration risks identified with affected components
- Conditions that would flip the verdict from kill to proceed
- Build the feature
- Validate with real users
- Write a PRD — use /prd-writer for that
- Make product decisions — it surfaces the evidence, you decide
Tips
You saved yourself from building something wrong. A kill verdict in 10 minutes is worth more than a week of wasted implementation.
"Someone would want this" is not user evidence. Name a specific person and describe exactly what they do today instead. If you can't, the user evidence check fails.
If the idea survives all five checks, use /prd-writer right away. The reasoning is still fresh and maps directly to acceptance criteria.
Get the Skill
Pressure Test
The full SKILL.md — copy it into ~/.claude/skills/ and trigger it by name.
Commonly Used With
29 more production skills ready to install.