---
name: stress-test
description: "Stress-test a plan or design from every angle, Claude Code Dynamic Workflows style. Spawns independent attackers (feasibility, security, edge cases, cost, alternatives), verifies the claims the plan rests on, and returns a verdict per section: KEEP / FIX / RETHINK. Invoke with /workflows:stress-test <plan or @plan-file>."
user-invocable: true
---

# Plan stress-testing workflow

One of the documented use cases of Claude Code's Dynamic Workflows: "a
plan you want stress-tested from every angle before you commit to it."
When the cost of a wrong plan is high, this workflow gives you
independent attempts at breaking it before you act on it.

The input after `/workflows:stress-test` is the plan (inline text, or a
file to read). If it is empty, ask for the plan first.

## Phase 1 — Read and restate

1. Read the plan fully. If it is a file, read it end to end first.
2. Restate it in one paragraph and list its load-bearing claims — the
   assumptions that, if wrong, invalidate the plan.
3. Write the run state to scratchpad: `workflows/<run-id>/plan.md` with
   run id `wf-stress-<slug>-<n>`, containing the plan summary, the
   claims, and the attack angles below.

## Phase 2 — Attack from independent angles

Spawn one `workflows:adversary` per angle (parallel, max 5), each with a
specific lens and the plan text:

| Angle | Attack lens |
|---|---|
| Feasibility | Does the plan fit the real codebase/infra? Hidden dependencies, wrong assumptions about what exists |
| Correctness | Edge cases, race conditions, failure modes, data shapes that break the flow |
| Security | Input validation, auth gaps, injection, secrets, unsafe patterns |
| Cost/scope | Underestimated effort, missing steps, things that silently double the work |
| Alternatives | Simpler/cheaper paths the plan ignores; is it over-engineered |

Spawn pattern (unique names, never reused):

```
tools.agents.spawn({
  name: "<run-id>-adv-feasibility",
  config_name: "workflows:adversary",
  message: "Lens: FEASIBILITY. Plan: <plan text>. Attack it from this
            angle only. BREAKER/RISK/NIT format."
})
```

Collect with the standard loop: `tools.self.sleep`, `tools.agents.list`,
one "reply now" nudge for stragglers via `tools.agents.send_message`.
Append replies to `workflows/<run-id>/adversarial.md`.

## Phase 3 — Verify the claims

For each load-bearing claim (max 6, the ones that actually matter), spawn
a `workflows:verifier` with the claim and how to check it — not the
plan's reasoning:

```
tools.agents.spawn({
  name: "<run-id>-v<NN>",
  config_name: "workflows:verifier",
  message: "Claim: <claim>. Verify it independently in this repo/context.
            CONFIRMED/REFUTED/UNCERTAIN with evidence."
})
```

Append verdicts to `workflows/<run-id>/verification.md`.

## Phase 4 — Converge into a verdict

1. One extra round max: if a BREAKER or a REFUTED claim suggests the plan
   is salvageable with changes, spawn one more adversary on the patched
   version ("plan' with these changes: ... — does it hold now?").
2. Produce the final report to the user, and save it to
   `workflows/<run-id>/report.md`:

```
VERDICT PER SECTION
- <section>: KEEP | FIX <what and why> | RETHINK <why>
CLAIMS
- <claim>: CONFIRMED | REFUTED | UNCERTAIN (evidence)
BREAKERS FOUND
- <list, or "none">
RISKS ACCEPTED IF YOU PROCEED
- <list>
BOTTOM LINE
- One paragraph: proceed, proceed with changes, or rethink.
```

## Rules

- Attackers attack, they do not redesign: proposals to fix come only in
  the verdict step, driven by evidence.
- Every objection must be concrete and checkable ("config X does not
  exist at path Y"), not generic ("might not scale").
- A plan that survives with zero findings after honest attacks should be
  told so — a survived attack is information, not a failure.
- Budget: max 5 attackers + max 6 verifiers + 1 extra round. Hard cap.