Stress Test

Parallel Adversarial Attack Surface Analysis. Spawns N independent agents, each tasked with BREAKING a system from a different attack angle. No agent sees others' findings. Synthesizes into a vulnerability map with severity ratings.

Arguments

$ARGUMENTS — format: [N] [path/to/code_or_design or inline description] where N is optional (default: 5, min 3, max 7)

Parse Arguments

Extract:

• agent_count: the optional leading integer (default 5, min 3, max 7)
• attack_target: the file path, directory path, or inline description of the system to analyze

If the target is missing or unclear, ask the user to clarify before proceeding.

Phase 1: Identify the Target

Determine the target type and build a comprehensive understanding:

• If a file or directory path is given: read and explore it to understand the system — its structure, components, dependencies, data flows, trust boundaries, and deployment model
• If an inline description is given: parse it for the same information

Prepare a target brief covering:

• What the system does (purpose, scope)
• Components and their responsibilities
• Dependencies (internal and external)
• Data flows (input sources, processing, storage, output)
• Trust boundaries (authenticated vs unauthenticated, internal vs external, admin vs user)
• Deployment model (where it runs, how it scales)

Present the target brief to the user and confirm before proceeding. Adjust if the user gives feedback.

Phase 2: Spawn Attack Agents

Launch all N agents in parallel using the Agent tool. Each agent gets the target brief plus a unique attack vector selected from this list (assign sequentially, wrapping if N quantity, but don't stop at the first one.

For code targets: READ the actual code. Reference specific files, functions, and line numbers. Do not reason abstractly when concrete evidence is available.

For design targets: identify specific component interactions, API contracts, or architectural decisions that break under your attack vector.

If an area is untestable without actually running the code, say so explicitly — do not offer false reassurance.

Output Format

Attack Vector: {vector_name}

Vulnerability 1: [name]

• Description: ...
• Attack scenario: 1. ... 2. ... 3. ...
• Evidence: [specific code reference or component]
• Severity: [Critical/High/Medium/Low]
• Exploitability: [Easy/Medium/Hard]
• Risk Score: [Severity x Exploitability]
• Fix: ...

[repeat for each vulnerability found]

Summary

• Vulnerabilities found: N
• Critical: N, High: N, Medium: N, Low: N

## Phase 3: Synthesize Vulnerability Map

After ALL agents return, produce a unified analysis with five sections:

### 1. Vulnerability Summary Table

All findings sorted by risk score (highest first):

| # | Vulnerability | Vector | Severity | Exploitability | Risk | Fix |
|---|--------------|--------|----------|---------------|------|-----|

### 2. Heat Map

Which components or areas appear across multiple attack vectors? List each component with the vectors that flagged it. Components appearing in 3+ vectors are the most dangerous spots.

### 3. Critical Path

The sequence of vulnerabilities that, if chained together, would cause the worst outcome. Describe the chain step-by-step: which vulnerability enables the next, what the attacker gains at each step, and what the final impact is.

### 4. Prioritized Fix List

Mitigations ranked by three factors:
- **Risk reduction** — how much total risk the fix eliminates
- **Implementation effort** — how hard the fix is to implement (Easy/Medium/Hard)
- **Breadth** — how many vulnerabilities the fix addresses

Present as a numbered list with rationale for the ordering.

### 5. Clean Areas

Components or areas that no agent found issues with. These are tentative "safe" zones — note that absence of findings is not proof of safety, especially for areas that are hard to analyze statically.

Save the full report to the working directory as `stress_test_{slugified_topic}.md`.

## Phase 4: Next Steps

Present the report to the user and ask:
- Should we fix the Critical and High items now?
- Run `/premortem` on the areas identified as most risky?
- Re-run `/stress-test` after fixes to verify they hold?

## Rules

- **Independence is critical**: agents must NOT share findings. Do not include other agents' findings or vector assignments in any agent's prompt.
- **All agents launch in a single parallel batch**: use one message with N Agent tool calls.
- **Specific, not generic**: every vulnerability must reference the actual target — its code, components, or design decisions. Generic security checklists are useless.
- **Constructive**: every finding must include a concrete fix.
- **For code targets**: agents must READ the actual code, not just reason abstractly. Reference specific files, functions, and lines.
- **No false reassurance**: if an area is untestable without running code, say so explicitly.
- **No filtering**: include all agent findings in the synthesis, even overlapping ones. Overlap across independent agents is a strong signal.
- **Attribute findings**: always note which attack vector produced which finding.

## Pipeline Position

Sits after `/diverge-prototype` as a validation gate:

/diverge-prototype (build) -> /stress-test (validate) -> pick winner

## Source & license

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

- **Author:** [sjarmak](https://github.com/sjarmak)
- **Source:** [sjarmak/agent-workflows](https://github.com/sjarmak/agent-workflows)
- **License:** MIT

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