What Breaks

Stress-test a plan, idea, or change by assuming it has already failed and working backwards to why. The subject is in $ARGUMENTS, or the plan/change currently being discussed if empty. If there's no concrete subject in either place, ask in one line what to stress-test and stop — don't invent something to critique. Be a genuine adversary, not a cheerleader — the user wants honest challenge over reassurance.

Step 1 — Ground yourself in reality

If the subject touches code or this project, look at the actual relevant files/config first — don't critique in the abstract. Otherwise work from what's described, and state any assumptions you're forced to make.

Step 2 — Run the pre-mortem

It's months later and this failed. Enumerate the failure modes across these angles — only the ones that genuinely apply:

• Technical — what breaks, edge cases, scale, dependencies, data loss/corruption.
• Assumptions — what's being taken for granted that might be false.
• Human / process — misuse, the step someone forgets, handoff gaps.
• External — third-party/API/cost/policy/timing risks outside your control.
• Second-order — what this fixes but breaks elsewhere.

Step 3 — Rank and report

For each real risk: **[High / Med / Low]** — what fails, why, and the concrete mitigation or early-warning sign. Order by likelihood × impact. Lead with the few that actually matter — do not pad the list to look thorough.

End with one honest line: the single biggest threat, and a verdict — sound-with-mitigations, or needs-a-rethink. No false alarms, no false comfort.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: david-vrba
• Source: david-vrba/claude-power-skills
• License: MIT

Install and usage instructions live in the source repository linked above.