qa-swarm:attack

You are orchestrating a QA Swarm analysis. The user's analysis prompt is:

"{$ARGUMENTS}"

Follow this pipeline exactly. Do not skip steps.

Timing

Track elapsed time for each phase. At the start of each step, run date +%s (Bash tool) to capture the Unix timestamp. Store these timestamps so you can compute durations at the end.

Step 1: SETUP + PRE-READ

Record the pipeline start time: run date +%s and store it as t_start.

1a. Build file tree and categorize

1. Use the Glob tool to list all source files (exclude node_modules, target, dist, build, .git, vendor, pycache)

2. Categorize every source file into tags based on file path and name:

   • auth: authentication, authorization, login, session, token, JWT, OAuth
   • api: route definitions, controllers, handlers, REST/GraphQL endpoints
   • db: database models, queries, migrations, ORM, repositories
   • io: file I/O, network calls, HTTP clients, external service calls, cache clients
   • state: shared state, global variables, singletons, concurrent data structures
   • config: configuration files, env vars, feature flags, deployment configs
   • logic: business logic, algorithms, state machines, data transformations
   • frontend: UI components, templates, client-side code
   • test: test files (note but do not assign to agents)
   • entry: entry points, main files, startup/shutdown code

   A file can have multiple tags. When in doubt, include the tag.

3. Store the full file tree (paths only).

1b. Auto-detect project type

Detect from file extensions, names, and directory structure:

• Primary language(s), framework(s), project type (library, CLI, web service, etc.)
• Notable characteristics: has CI, has Docker, has API spec, etc.

1c. Select optional agents

Based on detected project type:

• qa-config-env: projects with environment-dependent deployment (Docker, k8s, .env files)
• qa-type-safety: dynamically typed languages or projects without strict type checking
• qa-logging: services that run in production (web services, daemons)
• qa-backwards-compat: libraries, public APIs, or projects with external consumers
• qa-supply-chain: projects with third-party dependencies (package.json, Cargo.toml, go.mod, etc.)
• qa-state-mgmt: frontend apps or stateful services

1d. Pre-read all source files

This is the key performance optimization. Read ALL non-test source files and store their contents grouped by tag. This eliminates agent file-reading overhead -- agents receive code inline and analyze immediately with zero tool calls.

1. For each non-test source file, read it using the Read tool (cap at 750 lines per file -- if longer, read first 400 + middle 100 lines around the midpoint + last 150 lines with [... {N} lines omitted ...] markers between sections)
2. Group the file contents by tag. A file with multiple tags appears in multiple groups.
3. Format each file as:

   === {file_path} ===
   {file contents}
   

Launch multiple Read calls in parallel to speed up this phase.

1e. Print summary and confirm

QA Swarm -- Codebase Summary
==============================
Source files: {file_count}
Estimated lines: ~{line_count}

Detected: {language(s)} {framework(s)} {project_type}

Agents to deploy:
  Core (6):  Security & Error, Performance & Resources, Correctness, Architecture, Data Flow, Async Patterns
  Optional:  {list of selected optional agents, or "none"}

Estimated cost (API tokens):
  Small project  (< 50 files):   ~$0.30-0.80
  Medium project (50-200 files): ~$0.80-2.50
  Large project  (200+ files):   ~$2.50-6.00

Proceed? (Y/n, or adjust optional agents: "+logging -supply-chain")

Wait for user confirmation. If "n", stop. Parse any agent adjustments.

Record timestamp: t_setup_done.

Step 2: SWARM

Print:

[Phase 1/3] Deploying {N} QA agents in parallel...
  Core: Security & Error, Performance & Resources, Correctness, Architecture, Data Flow, Async Patterns
  Optional: {list or "none"}

Launch ALL agents (core + optional) IN PARALLEL in a single message. Each agent gets its scoped file CONTENTS embedded directly -- no file paths to read.

For each agent, use this prompt template:

You are being deployed as part of a QA swarm analysis.

MISSION: {user's original prompt}

IMPORTANT: All source code is provided inline below. Do NOT use the Read tool -- analyze the code directly from this prompt. This is a performance optimization to eliminate file-reading overhead.

FULL FILE TREE (for reference -- paths only):
{the file tree from Step 1}

YOUR SCOPED SOURCE CODE:
{the actual file contents for this agent's tagged files, formatted as === path === \n content}

{Read the agent definition file from agents/qa-{name}.md and include its full content here as the agent's instructions}

Analyze the code provided above according to your specialty. Return your findings as structured JSON.

Core agents and their scoped file contents:

1. qa-security-error (model: sonnet) -- receives contents of: auth + api + db + config + io + entry + logic files
2. qa-performance-resources (model: sonnet) -- receives contents of: db + io + api + logic + state + entry + config files
3. qa-correctness (model: sonnet) -- receives contents of: db + api + logic + io + config files
4. qa-architecture (model: sonnet) -- receives contents of: entry + api + logic + config + db + io files
5. qa-data-flow (model: sonnet) -- receives contents of: auth + api + db + io + logic + entry files
6. qa-async-patterns (model: sonnet) -- receives contents of: api + io + logic + state + db + entry files

Optional agents and their scoped file contents (if selected):

• qa-config-env (model: haiku): config + entry + io files
• qa-type-safety (model: haiku): logic + api + db files
• qa-logging (model: haiku): io + api + entry files
• qa-backwards-compat (model: haiku): api + db + config files
• qa-supply-chain (model: haiku): config files + dependency/package files
• qa-state-mgmt (model: haiku): state + frontend + logic files

Launch ALL in parallel (all in one message with multiple Agent tool calls).

Wait for ALL agents to complete. If any agent fails, log it and continue:

Agent {name} failed: {error}
Continuing with {N}/{total} agent results.

Record timestamp: t_swarm_done.

Step 3: INLINE AGGREGATION

Print:

[Phase 2/3] Aggregating and ranking findings...

Do NOT launch an agent for this step. Perform aggregation inline to save time.

3a. Merge and deduplicate

Combine all agent findings. Identify duplicates:

• Same file + same line range (within 5 lines) = duplicate
• Same file + same function + similar title = duplicate

For duplicates, keep the one with higher confidence and build a flagged_by array. Print:

Dedup: {original_count} findings -> {deduped_count} ({removed} duplicates merged)

3b. Validate severity

Review each finding's severity:

• P0 Critical must be actively exploitable, cause data loss, or crash production. If it's really a code smell, downgrade.
• P1 High must cause real problems under normal usage. Not theoretical.
• P2 Medium is for latent risks and code smells that will compound.
• P3 Low is for improvement opportunities.

Confidence gates:

• P0 requires confidence >= "likely" OR corroboration by 3+ agents
• P1 requires confidence >= "likely" OR corroboration by 2+ agents
• P2-P3 can have "suspected" confidence if evidence is quoted

If P0 but only "suspected" with no corroboration, downgrade to P1 or P2.

3c. Validate confidence

• "confirmed" requires a traceable path and quotable code snippet that is unambiguously wrong
• "likely" requires strong evidence with acknowledged runtime uncertainty
• "suspected" is for patterns that look wrong but could be intentional

Downgrade if evidence doesn't support the tag. No specific file path + code snippet = cannot be "confirmed."

3d. Apply corroboration scoring

• Normalize file paths before matching
• Match by: same file + same function, OR same file + line numbers within 5 lines
• Count distinct agents per issue
• 3+ agents: boost confidence one level if evidence supports it
• 2 agents: note corroboration, no auto-boost
• 1 agent: stands on its own

3e. Format the report

Compile the final report in this format:

# QA Swarm Report
**Date:** {DATE}
**Prompt:** "{ORIGINAL_PROMPT}"
**Agents deployed:** {COUNT} ({CORE_COUNT} core + {OPTIONAL_COUNT} optional)

## Summary
- P0 Critical: {N} findings
- P1 High: {N} findings
- P2 Medium: {N} findings
- P3 Low: {N} findings
- Total: {N} findings ({N} confirmed, {N} likely, {N} suspected)

## P0 - Critical

### [P0-001] {title}
**Confidence:** {confidence} | **Corroborated by:** {N} agents ({agent_list})
**Location:** {file}:{line} in `{function}`
**Description:** {description}
**Evidence:**
\`\`\`
{evidence}
\`\`\`
**Suggested fix:** {suggested_fix}
**Related files:** {related_files}

## P1 - High
(same format)

## P2 - Medium
(same format)

## P3 - Low
(same format)

Rules:

• Number findings sequentially: P0-001, P0-002, P1-001, etc.
• Every finding MUST have file path, line number, and evidence
• Remove findings that lack concrete evidence
• Merge findings that describe the same issue, crediting all agents
• The report must be self-contained
• Do NOT add your own findings -- only organize what agents found
• Be conservative. A report full of P0s loses credibility.

Record timestamp: t_agg_done.

Print a table of ALL findings sorted by severity then confidence:

Findings Summary
==================

| ID     | Severity | Confidence | Title                          | Location                        | Corroborated By   |
|--------|----------|------------|--------------------------------|---------------------------------|--------------------|
| P0-001 | P0       | confirmed  | SQL injection in login handler | src/auth.ts:42 `handleLogin()`  | 3 agents (SEC,ERR) |
| ...    | ...      | ...        | ...                            | ...                             | ...                |

Print every finding -- do not truncate.

Step 4: FIX PLANNER

Print:

[Phase 3/3] Generating implementation spec and test plan...

Launch ONE agent:

qa-fix-planner (model: sonnet):

• Receives the final ranked report (full markdown from Step 3)
• Has access to the codebase (to read existing test patterns and verify P0 evidence)
• Produces BOTH the implementation spec AND the test plan

Read the agent definition from agents/qa-fix-planner.md and include its full content in the prompt.

Record timestamp: t_output_done.

When the agent returns, split its output on the ===SPEC_START=== / ===SPEC_END=== / ===TESTS_START=== / ===TESTS_END=== delimiters to extract the two documents.

Step 5: SAVE + HANDOFF

Print:

Saving reports...

Get today's date and save the three output files:

1. Write the report (from Step 3) to docs/qa-swarm/{DATE}-report.md
2. Write the spec (from Step 4) to docs/qa-swarm/{DATE}-spec.md
3. Write the test plan (from Step 4) to docs/qa-swarm/{DATE}-tests.md

Create the docs/qa-swarm/ directory if it does not exist.

Record timestamp: t_save_done.

Compute phase durations (format as Xm Ys):

• Setup + Pre-read: t_setup_done - t_start
• User Confirm: (skip from total)
• Agent Swarm: t_swarm_done - t_setup_done
• Aggregation: t_agg_done - t_swarm_done
• Fix Planner: t_output_done - t_agg_done
• Save Files: t_save_done - t_output_done
• Total: t_save_done - t_start minus user confirm wait

Count agents dispatched:

• Core agents: always 6 (Sonnet)
• Optional agents: count selected (Haiku)
• Fix Planner: always 1 (Sonnet)

QA Swarm Analysis Complete
============================
Findings: {total} ({P0} P0, {P1} P1, {P2} P2, {P3} P3)
Confidence: {confirmed} confirmed, {likely} likely, {suspected} suspected

Phase Timing:
  Setup + Pre-read  {Xm Ys}
  Agent Swarm       {Xm Ys}   ({N} agents in parallel: 6 Sonnet core + Haiku optional)
  Aggregation       {Xm Ys}   (inline -- no agent)
  Fix Planner       {Xm Ys}   (1 Sonnet agent)
  Save Files        {Xm Ys}
  ────────────────────────
  Total             {Xm Ys}   (excludes user confirmation wait)

Agent Usage:
  Sonnet : {6 + 1} agents  (6 core + 1 fix planner)
  Haiku  : {optional_count} agents  ({optional_count} optional)
  Opus   : 0 agents
  Total  : {7 + optional_count} agents dispatched

Report:    docs/qa-swarm/{DATE}-report.md
Spec:      docs/qa-swarm/{DATE}-spec.md
Test Plan: docs/qa-swarm/{DATE}-tests.md

Step 6: AUTO-HANDOFF TO IMPLEMENT (fresh-context subagent)

Immediately after printing the summary, auto-invoke the implement phase in a fresh-context subagent. The subagent starts with zero context from attack -- this is the functional equivalent of /clear before running implement, without requiring manual user action.

Ask the user once:

Proceed to implementation now? [Y/n]
(Selecting Y hands off to a fresh-context subagent running /qa-swarm:implement.
 Selecting n stops here -- you can resume later by running:
   /qa-swarm:implement docs/qa-swarm/{DATE}-report.md docs/qa-swarm/{DATE}-spec.md docs/qa-swarm/{DATE}-tests.md)

If the user declines (n), STOP.

If the user confirms (Y or empty), spawn a general-purpose Agent with the following self-contained prompt (the subagent has no access to this session's context, so the prompt MUST stand alone):

You are executing the qa-swarm:implement skill in a fresh session.

Invoke the Skill tool with:
  skill: "qa-swarm:implement"
  args: "{report_abs_path} {spec_abs_path} {tests_abs_path}"

All three files already exist on disk. Read them fresh. Follow the skill
exactly -- including phase selection (present the table, wait for user input
via AskUserQuestion), TDD setup (3 parallel test-writer agents), phase
execution, and final results report.

When the skill completes, return a concise summary: phases run, issues fixed,
issues unresolved, test pass/fail counts, and the path to the results file.
Do not re-describe work the user already saw -- just the outcome.

Use absolute paths for the three files so the subagent's path resolution does not depend on any shared working-directory state.

When the subagent returns, print its summary verbatim and STOP.