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
- TRIGGER: Plan, idea, or decision — A spec, PR, strategy memo — anything you're attached to
- STEP 1: Premortem — It failed 6 months out — name the false assumption that killed it
- STEP 2: Blind spots — Cynical competitor view — how they'd exploit the weaknesses
- STEP 3: Risk ranking — Top 3 risks scored likelihood × impact, each with a contingency
- OUTPUT: Verdict + top 3 changes — Survivability call · load-bearing assumption · fix before proceeding
- 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
New skills ship here first
That one's yours — keep it. The library grows every week. Get each new production skill the day it drops, free, and follow the build along the way.
Get every new skill free30 production skills in the library — ready to install.