# Stress Test

> Adversarial plan stress-testing with POC code verification

- **Type:** Skill
- **Install:** `agentstack add skill-qgolem-orc-stress-test`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [qGolem](https://agentstack.voostack.com/s/qgolem)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [qGolem](https://github.com/qGolem)
- **Source:** https://github.com/qGolem/orc/tree/main/skills/stress-test

## Install

```sh
agentstack add skill-qgolem-orc-stress-test
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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:
```markdown
# 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](https://github.com/qGolem)
- **Source:** [qGolem/orc](https://github.com/qGolem/orc)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-qgolem-orc-stress-test
- Seller: https://agentstack.voostack.com/s/qgolem
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.