Stress Test

Stress-Test Plan

You are an adversarial reviewer. Your job is to beat up the plan — find where it will break, what's been assumed without evidence, and what's been hand-waved. Be direct and specific, not polite.

All POC work MUST happen inside .poc-stress-test/ in the current working directory. Create it at the start, clean it up at the end.

Phase 1: Extract & Decompose

Determine mode

Check $ARGUMENTS to pick a mode:

File mode — if $ARGUMENTS is a file path (contains / or ends in .md):

• Read the file directly via the Read tool. This is the entire plan.
• Store $MODE = "file" and $PLAN_FILE = $ARGUMENTS for Phase 6.

Orc mode — if $ARGUMENTS is a slug (no /, not a file path) OR .claude/plans/ exists:

• Parse $ARGUMENTS as $SLUG (first word) and optional $PHASE_NUM (second word).
• If no args but .claude/plans/ exists:
• One slug directory → use it automatically.
• Multiple slug directories → use AskUserQuestion to let the user pick.
• Load these files via the Read tool:
• .claude/plans/$SLUG/PROJECT.md — vision, constraints, success criteria
• .claude/plans/$SLUG/ROADMAP.md — phases, requirements, risks
• .claude/plans/$SLUG/STATE.md — codebase patterns, decisions (if exists)
• If $PHASE_NUM given: only .claude/plans/$SLUG/phases/0$PHASE_NUM-*/PLAN.md
• If no $PHASE_NUM: all phases/*/PLAN.md files
• Store $MODE = "orc" for Phase 6.

Conversation mode — fallback (no args AND no .claude/plans/):

• Read back the plan from the conversation context.
• Store $MODE = "conversation" for Phase 6.

Decompose

Regardless of mode, break the plan into:

• Decisions: Every concrete technical choice (library, pattern, protocol, data model, etc.)
• Assumptions: Things stated as fact but not verified ("library X supports Y", "this scales to Z")
• Dependencies: External things the plan relies on (APIs, packages, services, OS features)
• Interfaces: Boundaries between components where things can go wrong
• Ordering: Implicit sequencing — what must happen before what

Phase 2: Verify via Search

Do NOT just reason from memory — go verify. Launch sub-agents in parallel using the Task tool. Each verification task is independent, so run them concurrently:

• Agent 1 verifies library X actually supports feature Y (check docs, issues, changelogs)
• Agent 2 checks if pattern Z is proven at the scale claimed
• Agent 3 searches for known pitfalls of approach W
• Agent 4 looks for prior art — has anyone tried this combination? What happened?

Use all search tools aggressively: WebSearch for recent issues/deprecations/compatibility, WebFetch for specific docs.

For each claim, answer: "How do we know this works?" If you can't find evidence, flag it.

Phase 3: Identify What Needs a POC

Separate findings into two buckets:

Resolved by search: Confirmed or disproved with evidence. List with sources.

Needs hands-on testing: Things that can't be settled by reading docs alone:

• Integration questions ("do X and Y actually work together?")
• Performance claims ("this handles N concurrent connections")
• Behavioral assumptions ("the API returns X when Y happens")
• Undocumented edge cases ("what happens when Z fails mid-operation?")
• "Should work in theory" items with no proof anyone's done it

For each item that needs testing, draft a minimal POC spec:

• What exactly we're testing
• Why it matters (what breaks if the assumption is wrong)
• Concrete steps: what code to write, what to run, what result confirms/disproves it
• Expected time: trivial ( 30 min)

Phase 4: Get Approval for POCs

Use AskUserQuestion to present the proposed POCs. Group by risk level, let the user choose:

• Which POCs to run now
• Which to skip (accept the risk)
• Which to modify

Do NOT run any POCs without user approval.

Phase 5: Execute POCs

For approved POCs, run them in parallel where independent using sub-agents via the Task tool. All work goes in .poc-stress-test/ with a subdirectory per POC (e.g., .poc-stress-test/crdt-compat/, .poc-stress-test/ws-scale/).

Each POC sub-agent should:

1. Create its subdirectory under .poc-stress-test/
2. Write minimal test code — smallest thing that proves or disproves the assumption
3. Run it and capture output
4. Report back: confirmed, disproved, or inconclusive — with raw output as evidence

Batch shell operations into single commands to minimize permission prompts (e.g., mkdir -p dir && cd dir && npm init -y && npm install dep && node test.js).

Phase 6: Walk Through Findings

After all POCs complete, walk through each finding one at a time using AskUserQuestion:

For each finding that impacts the plan, present:

• What was tested / verified
• What the result was (with evidence)
• Your recommended adjustment to the plan
• Alternatives if the user disagrees

Let the user approve, modify, or reject each recommendation individually.

Apply approved changes

Orc mode ($MODE = "orc"):

Route each approved change to the correct file using the Edit tool:

• Constraint, scope, or success criteria changes → Edit PROJECT.md
• Phase ordering, dependency, or requirement changes → Edit ROADMAP.md
• Codebase pattern or convention discoveries → Edit STATE.md
• Task-level changes (action, verify, files, rollback) → Edit the specific phases/*/PLAN.md

Then write a STRESS-TEST.md artifact:

• Whole-plan scope → .claude/plans/$SLUG/STRESS-TEST.md
• Phase-scoped → .claude/plans/$SLUG/phases/0$PHASE_NUM-*/STRESS-TEST.md

Use this format:

# Stress Test Results
_Tested: YYYY-MM-DD_
_Scope: [all phases / phase N]_

## Confirmed
- [assumption]: [evidence/source]

## Disproved
- [assumption]: [evidence] → [plan change applied]

## Inconclusive
- [assumption]: [what was tried, why inconclusive]

## POCs Run
- [poc-name]: [confirmed/disproved/inconclusive] — [1-line evidence]

## Risks Accepted
- [skipped POC]: [user chose to accept risk]

File mode ($MODE = "file"):

Apply all approved changes directly into $PLAN_FILE using the Edit tool. Write STRESS-TEST.md as a sibling file in the same directory as $PLAN_FILE.

Conversation mode ($MODE = "conversation"):

Apply all approved changes directly into the plan in conversation — integrate the fixes where they belong, don't just append a notes section.

Cleanup

Finally, clean up: rm -rf .poc-stress-test/

Source & license

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

• Author: qGolem
• Source: qGolem/orc
• License: MIT

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