stress-test

Stress Test: Adversarial Design Interrogation

Announce at start: "I'm using the stress-test skill to interrogate this design."

Purpose

Stress-test a design, plan, or decision by walking down every branch of the decision tree. For each question, provide your own recommended answer — don't just ask, propose. This forces the user to either agree explicitly or articulate why their approach is better.

This is NOT brainstorming (which creates designs) or verification (which checks implementations). This is the gap between them: "Is this design actually solid before we commit to building it?"

When to Invoke

Trigger	Context
After brainstorming	Stress-test the design spec before writing a plan
After writing-plans	Stress-test the plan before execution begins
User says "grill me"	On-demand for any document, decision, or approach
Before a major architectural decision	Ensure alternatives were genuinely considered

The Process

# Create a stress-test bead
bd create "Stress-test: <topic>" -t chore -p 2 \
  --description="Adversarial review of <artifact>. Branches to interrogate: <count>"
bd update <id> --claim

Phase 1: Understand the Target

Read the design, plan, or decision document thoroughly. If no document exists, ask the user to describe the approach. Explore the codebase for context — answer your own questions from code when possible rather than asking the user.

Restore point (Mode A only): If the target artifact has uncommitted changes, commit or stash them before starting — this preserves a clean restore point before inline edits begin. In the normal flow (brainstorming → stress-test), the artifact is already committed.

Done when: the target is understood well enough to enumerate its decision branches, and (Mode A) the artifact sits at a clean restore point.

Phase 2: Map the Decision Tree