/orchestrating-vulnerability-research

name: orchestrating-vulnerability-research
description: Run a sustained, multi-agent vulnerability-discovery campaign against a target — split its attack surface into slices, hunt each slice with a builder agent, and have a separate critic with fresh context adversarially refute every candidate against the real artifact (a reproduced crash, a working request, a proven bypass) before it counts as a finding. Use when tasked to find previously-unknown bugs across a whole codebase, a binary, or a named live target; when you want to fan out many agents and loop until findings are proven rather than plausible; or when a single audit pass has stalled and you need builder/critic separation so the hunter never grades its own work. Dispatches auditing-code-for-vulnerabilities, analyzing-binaries, and testing-web-applications as the per-slice hunters and hands proven findings to reporting-security-findings.
verified: 2026-07-28

Orchestrating Vulnerability Research

One agent hunting one target rationalizes. It finds a "probably exploitable" path, writes a confident paragraph, and grades its own paragraph as a finding. The paragraph is not the bug. This skill is the harness that stops that: give the hunt a bar it cannot talk its way around, split the target so pieces are worked in parallel, and never let the agent that built a candidate be the one that decides it is real.

It is a *loop*, not a pass. You run it until findings are proven or the target is genuinely exhausted — not until the first plausible writeup appears.

When to Use

• Told to find previously-unknown vulnerabilities in a whole codebase, a

binary, or a named live target, with room to run many agents

• Running a bug-bounty or research campaign where depth and novelty matter more

than a one-pass coverage report

• A single audit or test pass has stalled or produced only unproven "maybe"

findings, and you want independent critics to break or confirm them

• You have the budget to fan out and iterate, and want the builder/critic

separation and a demonstrated-trigger bar enforced across the whole effort

When NOT to Use

• **One focused review of a source tree for coverage** (client audit, one pass,

a deliverable coverage table) — use `auditing-code-for-vulnerabilities` directly; this skill *dispatches* it, it does not replace it

• **Reversing or triaging a single binary** — use `analyzing-binaries`
• **Black-box testing one web app or API methodically** — use

`testing-web-applications` or `testing-apis`

• **Writing up the confirmed findings** — use `reporting-security-findings`
• **Tracking the campaign's evidence, provenance, and dead ends** — use

`maintaining-engagement-state`; this skill produces that record, it does not define its format

• **Hunting a webshell or backdoor someone already planted** (not a latent

vulnerability) — use `hunting-web-backdoors`

• **A stateless spot check** — "is this one function injectable?" is one

builder call, not a campaign. The harness overhead only pays off at scale.

The Loop

Five roles, run as a loop over each slice of the target. The lead never hunts and never grades; it decomposes, dispatches, and reconciles.

decompose → build → critique → iterate → smooth
   lead      hunter   critic     hunter    lead

1. Decompose — split into the smallest independently-huntable slices

The lead breaks the target into pieces that can each be hunted and judged on their own, without cross-talk. A good slice has one entry surface and a bounded reachable set. Slice by whichever axis makes pieces independent:

| Target | Slice by | | --- | --- | | Codebase | Entry point (route/handler/consumer), or bug class × component | | Binary | Exported/reachable function cluster, parser, or IPC/RPC surface | | Named live target | Host/service, then endpoint or protocol |

Write the slice list down before dispatching. A slice carries: what it covers, the reachable sink set, and the bar a finding here must clear (below). Slices that share state are a smell — merge them, or the critics will disagree because they saw different halves.

2. Build — a hunter per slice, told the goal, not the method

Dispatch one builder agent per slice with fresh context, pointed at the right domain skill for that artifact (`auditing-code-for-vulnerabilities`, `analyzing-binaries`, `testing-web-applications`). Give it the slice, the assets to protect, and the bar — **not** a script of steps. Told how, it performs the steps and reports success; told the goal and the bar, it has to actually reach them. Each hunter returns *candidates*: `(location, bug class, the trigger it claims, the evidence it has)`.

Run slices in parallel; they are independent by construction. Depth per slice beats breadth across slices — one fully triggered bug is worth twenty "suspicious" notes.

3. Critique — a separate critic, fresh context, told to refute

This is the rule the whole skill exists to enforce: **the builder never grades its own work.** Each candidate goes to a *different* agent with fresh context whose job is to *refute* it, and which inspects the real artifact — the running binary, the actual HTTP response, the executed test, the re-read source — never the hunter's summary of it.

The bar is a *demonstrated trigger*, and the critic asks only whether it was met:

• Codebase: is there a concrete input that reaches the sink with attacker

control intact, past every validator on the path? Not "looks reachable."

• Binary: does it crash or corrupt state *under a controlled input*, with the

fault understood? Not "this `memcpy` looks unbounded."

• Live target: did the request produce the anomalous response that proves the

weakness, reproducibly? Not "the error suggests injection."

If the bar is not met, the critic names the single biggest gap between the candidate and a proven bug — the missing reachability step, the validator the hunter did not account for, the input it never actually ran. That gap