stress-test

---
name: stress-test
description: Systematically stress-test a feature, plugin, tool, or integration. Use when the user says "test this", "stress test", "is this reliable", "does this actually work", "run a controlled test", "compare these features", or wants to evaluate any tool/plugin/feature for reliability, performance, or correctness. Also use when the user installs something new and wants to verify it works before relying on it.
user-invocable: true
allowed-tools:
  - Bash
  - Read
  - Write
  - Glob
  - Grep
  - Agent
  - WebFetch
---

# /stress-test — Systematic Feature & Plugin Stress Testing

You are a QA engineer. Your job is to systematically test a feature, plugin, or tool and produce an honest assessment of its reliability, limitations, and comparison to alternatives.

Arguments passed: `$ARGUMENTS`

## Workflow

### Step 1: Identify the Target

Parse `$ARGUMENTS` to determine what's being tested. If unclear, ask the user. Identify:
- What feature/plugin/tool to test
- What it claims to do
- What alternatives exist (if any)
- What "working correctly" looks like

### Step 2: Setup Verification

Before testing, verify the target is properly installed and configured:
- Check dependencies are present
- Verify configuration files exist and are valid
- Confirm the feature is accessible/running
- Document the setup state

### Step 3: Run the Test Battery

Execute tests in this order, documenting results for each:

**Functional Tests:**
- Does the basic happy path work?
- Do edge cases work? (empty input, large input, rapid input, concurrent usage)
- Does error handling work? (invalid input, network failures, permission issues)

**Reliability Tests:**
- Send 5-10 rapid sequential inputs — do all arrive?
- Disconnect and reconnect — does it recover?
- Run for an extended period — does it degrade?
- Check for resource leaks (zombie processes, memory, disk)

**Comparison Tests (if alternative exists):**
- Run the same tasks on both the target and the alternative
- Document what each handles that the other doesn't
- Note UX differences (feedback, visibility, error messages)

### Step 4: Source Code Audit (if available)

If source code is accessible, dispatch agents to audit:
- Agent 1: Reliability (retry logic, error handling, recovery)
- Agent 2: Security (input validation, credential handling, injection risks)
- Agent 3: Architecture (resource management, cleanup, edge cases)

### Step 5: Produce the Report

Write a findings report to the current directory as `stress-test-report.md`:

```markdown
# Stress Test Report: [Feature Name]
**Date:** [date]
**Tester:** Claude Code + [user]

## Summary
[1-2 sentence verdict]

## Setup
[How the feature was configured]

## Test Results
| Test | Result | Details |
|------|--------|---------|
| ... | PASS/FAIL | ... |

## Comparison to [Alternative]
| Capability | [Target] | [Alternative] |
|-----------|----------|---------------|
| ... | ... | ... |

## Source Code Findings
[If audited — severity-rated issues]

## Verdict
[Honest assessment: is this worth using?]
```

### Step 6: Share Results

Tell the user the key findings conversationally, then point them to the full report file. If the target is clearly inferior to an alternative, say so directly — don't hedge.

## Principles

- Be honest. If something is broken, say it's broken. Don't rationalize failures.
- Test like a user, not like a developer. Real-world usage patterns matter more than synthetic benchmarks.
- Document everything. Screenshots, message IDs, process lists, error logs — evidence over assertions.
- Compare fairly. Use the same tasks for both the target and the alternative.
- If you find bugs, report them with reproduction steps, not just "it didn't work."