Spark
Sign In
Skill

Hunt bugs with four-agent investigation swarm

A parallel multi-agent bug-investigation skill - four read-only investigators, ranked root-cause hypotheses, no fixes applied.

Get skill
Dimillian
Maintainer?
42
Spark score
out of 100
Updated 3 months ago
Version 1.0.0
Add to Favorites

Why it matters

Run a coordinated four-agent investigation to identify the root cause of a bug by reproducing the issue, tracing the code path, finding potential regressors, and determining the fastest proof step, then deliver a ranked root-cause analysis.

Outcomes

What it gets done

01

Reproduce the reported bug in a controlled environment

02

Trace the execution path through the codebase to isolate the failure point

03

Identify potential regression commits or changes that introduced the bug

04

Recommend the fastest validation step to confirm the root cause

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-bug-hunt-swarm | bash

Overview

Bug Hunt Swarm

This skill launches four parallel read-only sub-agents to investigate a bug from different angles - reproduction, code path, regression history, and proof plan - then synthesizes ranked, evidence-backed root-cause hypotheses without applying any fix. Use it for investigating bugs, regressions, crashes, or flaky failures needing a ranked root-cause diagnosis. It does not implement fixes - that's explicitly out of scope.

What it does

This skill investigates a bug using four read-only sub-agents launched in parallel, then has the main agent rank the likely causes and recommend the fastest path to prove or fix the issue - explicitly diagnosis-first, never editing files or implementing fixes itself. It first builds a bug packet covering symptom, expected versus actual behavior, reproduction steps, scope of impact, and evidence like logs, stack traces, failing tests, screenshots, or diffs, preferring the user's own description, then explicit provided evidence, then recent git history if the bug looks regression-like, then the smallest relevant code path - inferring a minimal problem statement and naming what's still unknown if the report is underspecified, and reading the closest project instructions and docs for the affected subsystem first. It then writes a short investigation brief bounding what's broken, unproven, most likely involved, already evidenced, and what would count as confirmation, using read-only tools such as ripgrep and git diff, log, and show, reading logs, traces, and config, and existing test runs, without editing files or adding instrumentation.

Four parallel read-only investigators each get the same bug packet and brief, are explicitly told they're read-only with no edits, patches, staging, or commits allowed, and must return only a hypothesis, supporting evidence, missing evidence, smallest proof step, and confidence level, avoiding generic code-quality feedback or speculation without evidence. One investigator clarifies the exact failure shape and boundary conditions, such as the narrowest trigger and whether the bug is deterministic or flaky; a second traces the likely execution path and failure seam, checking state transitions, caller and callee mismatches, and data or control-flow breaks; a third investigates recent changes and regressions, checking correlated diffs, configuration or schema drift, and partial multi-entry-point updates; a fourth determines the fastest proof plan, identifying the smallest failing test, the most useful logs or traces, and a minimal non-mutating confirming command. For tiny, obvious issues, investigating locally instead of launching the full swarm is acceptable.

The main agent then synthesizes the results: merging duplicate hypotheses, discarding weak speculation, preferring evidence over elegance, separating root causes from mere contributing factors, and normalizing survivors into a hypothesis, evidence, missing-evidence, proof-step, and confidence shape - saying so directly if the evidence is too weak for a real ranking rather than forcing one. The final output orders the most likely root cause, plausible alternate causes, the fastest proof step, a recommended fix path, and open questions or blockers, optionally grouped into prove-now, fix-next, and follow-up-later buckets, explicitly without implementing any fix.

When to use - and when NOT to

Use it to investigate bugs, regressions, crashes, flaky behavior, or unexplained failures that need a ranked root-cause diagnosis - not for actually implementing the fix, which is out of scope for this skill by design.

Inputs and outputs

Given a bug description and available evidence, it produces a synthesized, ranked set of root-cause hypotheses with supporting and missing evidence, a recommended smallest proof step, and a suggested fix path - no code changes are made.

Integrations

Read-only shell and git tooling such as ripgrep and git diff, log, and show, existing test runs, and the sub-agent orchestration mechanism used to launch four parallel investigators in reviewer or explorer roles.

Who it's for

Developers debugging a non-obvious failure who want fast, evidence-backed root-cause hypotheses from multiple investigation angles before committing to a fix, rather than guessing from a single vantage point.

Source README

Bug Hunt Swarm

When to Use

Use this skill when you need parallel read-only multi-agent root-cause investigation for bugs, regressions, crashes, flaky behavior, or unexplained failures. Use when the user asks to investigate a bug, find the root cause, trace a regression, understand why something broke, or wants a ranked diagnosis with the...

Investigate a bug with four read-only sub-agents in parallel, then have the main agent rank the likely causes and recommend the fastest path to prove or fix the issue. This skill is diagnosis-first: do not edit files or implement fixes as part of this workflow.

Step 1: Build the Bug Packet

Start by collecting the smallest useful investigation packet:

  1. Symptom
  2. Expected behavior
  3. Actual behavior
  4. Reproduction steps, if known
  5. Scope of impact
  6. Relevant evidence, such as logs, stack traces, failing tests, screenshots, recent diffs, or environment details

Prefer this source order:

  1. Direct user description
  2. Explicit files, stack traces, logs, tests, or screenshots provided by the user
  3. Current git changes or recent repo history when the bug appears regression-like
  4. The smallest relevant code path or subsystem surrounding the failure

If the bug report is underspecified, infer a minimal problem statement and say what is still unknown.

Before launching sub-agents, read the closest project instructions and relevant docs for the touched area, such as:

  • AGENTS.md
  • repo workflow docs
  • architecture, state, routing, schema, or runtime docs for the affected subsystem

Step 2: Bound the Investigation

Write a short investigation brief for the swarm:

  1. What appears broken
  2. What is not yet proven
  3. What part of the system is most likely involved
  4. What evidence already exists
  5. What kind of proof would count as confirmation

Use read-only evidence gathering where useful:

  • rg, git diff, git log, git show
  • reading logs, crash traces, and config
  • existing test runs or the smallest safe reproduction command

Do not edit files, inject new instrumentation, or implement fixes as part of this skill.

Step 3: Launch Four Read-Only Investigators in Parallel

Launch four sub-agents when the problem is large or ambiguous enough that parallel investigation helps. For a tiny and obvious issue, it is acceptable to investigate locally instead.

For every sub-agent:

  • give the same bug packet and investigation brief
  • state that the sub-agent is read-only
  • do not let the sub-agent edit files, run apply_patch, stage changes, commit, or perform any other state-mutating action
  • ask for concise investigation output only
  • ask for: hypothesis, supporting evidence, missing evidence, smallest proof step, and confidence
  • tell the sub-agent to avoid generic code quality feedback, nits, or speculative guesses without evidence
  • tell the sub-agent to send findings back to the main agent only

Use these four investigation roles.

Sub-Agent 1: Reproduction and Scope Investigation

Clarify the exact failure shape and its boundaries.

Check for:

  1. The narrowest reliable trigger
  2. Conditions that make the bug appear or disappear
  3. Expected versus actual behavior at the failure boundary
  4. Whether the impact is local, cross-cutting, deterministic, or flaky

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: reviewer

Sub-Agent 2: Code Path and Failure Seam Investigation

Trace the most likely execution path and identify the seam where behavior diverges.

Check for:

  1. State transitions, lifecycle edges, or ordering problems
  2. Mismatched assumptions between caller and callee
  3. Data-flow or control-flow breaks
  4. The smallest code region most likely responsible for the failure

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: explorer for broad tracing, or reviewer when a stronger local reasoning pass is more useful

Sub-Agent 3: Recent Change and Regression Investigation

Look for likely regressors in nearby history or changed contracts.

Check for:

  1. Recent diffs that correlate with the symptom
  2. Config, flag, dependency, schema, or migration drift
  3. Partial updates where several entry points should have changed together
  4. Behavior changes that fit the timing of the bug report

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: reviewer

Sub-Agent 4: Proof Plan and Observability Investigation

Determine the fastest way to confirm or reject the leading hypotheses.

Check for:

  1. The smallest existing test or reproduction that should fail
  2. The most useful current logs, traces, metrics, or assertions
  3. A minimal non-mutating command that could raise confidence quickly
  4. What evidence is missing and how to collect it without broad churn

This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.

Recommended sub-agent role: reviewer

Report only hypotheses that materially improve the odds of finding the real cause. It is better to return two evidence-backed theories than six vague guesses.

Step 4: Synthesize Ranked Hypotheses

The main agent owns synthesis. Treat sub-agent output as raw investigation input, not final output.

Merge and rank the hypotheses:

  • combine duplicates
  • discard weak speculation
  • prefer evidence over elegance
  • separate likely root causes from mere contributing factors
  • keep alternate theories only when they remain plausible

Normalize the surviving hypotheses into this shape:

  1. Hypothesis
  2. Supporting evidence
  3. Missing or conflicting evidence
  4. Smallest proof step
  5. Confidence: high, medium, or low

If the evidence is too weak for a real ranking, say so directly and present the leading open questions instead.

Step 5: Output a Clear Diagnosis Path

Present the result in this order:

  1. Most likely root cause
  2. Plausible alternate causes, if any
  3. Fastest proof step
  4. Recommended fix path
  5. Open questions or blockers

When the fix is not yet clear, recommend the next proving step instead of pretending the diagnosis is complete.

When helpful, group actions into:

  • prove now
  • fix next
  • follow up later

Do not implement fixes as part of this skill. The output is a read-only diagnosis with a prioritized path forward.

Limitations

  • Use this skill only when the task clearly matches its upstream source and local project context.
  • Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
  • Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.