/raptor-loop-hunt

name: raptor-loop-hunt
description: >-
  Autonomous, looping, multi-altitude security vulnerability hunting for source code using RAPTOR's
  inventory-first generate-judge-verify methodology. Use by default when the user points to a repo,
  service, app, module, or directory and asks to audit, pentest, security-review, find bugs, or find
  anything exploitable. Depth cues such as go deep, find every bug, exhaustive, maximum coverage,
  keep hunting, verified not guessed, auto-research, or file/function-by-function strengthen the
  match, but a plain source-code security audit also qualifies. Do not use for webserver/config-only
  audits, one known-CVE reproduction, a one-file/function sanity check, dependency/SCA lookup, PR or
  style review, debugging one specific crash, or attack-surface mapping without vulnerability hunting.

RAPTOR Auto-Research Vuln Hunt

A natural-language agent loop for security research. A generic "find bugs" prompt lets the model fall back to its defaults — single pass, mid-level altitude, converge fast, summarize, stop. Those defaults are wrong for vuln hunting. This skill replaces them with an explicit search procedure: traverse every altitude, generate then adversarially verify from raw, run isolated parallel reasoners, and keep a persistent ledger so each loop is net-new coverage instead of rediscovery.

**The prompt is the program.** In an agentic system the model's "algorithm" is whatever you tell it to be. This skill specifies that algorithm. Follow the structure; the quality comes from the structure, not from any single clever instruction.

When to use

Use for any "go deep / find everything / audit this thoroughly" security request against a codebase. Don't use for a quick triage, a single known-CVE reproduction, or a one-file sanity check — those want `/scan` or `/understand --hunt` directly. This is the heavy, looping, high-coverage mode.

The core loop

Run this as a loop, not a one-shot. Each round:

1. **Pick an altitude and a slice** you have not exhausted (see traversal below). 2. **Generate** candidate findings on that slice with an *independent* reasoner working **from raw source** (no prior summaries in its context — summaries cause anchoring). 3. **Judge** each candidate with a *separate* reasoner, also from raw, prompted to refute. 4. **Live-verify** survivors against the actual code before they count (see guardrails). 5. **Record** everything tried and everything found in the ledger. 6. **Vary** the approach next round — new altitude, new bug-class lens, new slice. Novelty is mandatory; repeating a round wastes budget. 7. **Check the stop condition.** Loop until dry, not literally forever.

Multi-altitude traversal (the coverage guarantee)

Different bug classes live at different zoom levels. A single-pass scan implicitly picks one altitude and is structurally blind to the others. Cover all four, in order, and revisit:

• **Whole project** — architecture, trust boundaries, auth model, data flows across modules.

Catches the broken-object-level-authz / IDOR / missing-authz class that dominates real web audits, plus deserialization sinks, SSRF, and design-level bypasses.

• **File by file** — each file's responsibilities, its inputs, its exported surface.
• **Functionality by functionality** — each feature end to end (upload, import, export,

templating, auth, admin actions). Trace source → sink for **every bug class**, not just the headline one. A mapped-but-untraced entry point is an uncovered entry point.

• **Function by function** — parsing, memory, encoding, length math, crypto comparisons,

format strings, integer handling. Line-level bugs only surface here. This is the altitude with the weakest mechanical support — the Semgrep anchors above are seeded from *whole-project* trust boundaries, so nothing systematically walks the interior functions no entry-point cell anchors. RAPTOR's `/audit` can be used as an **experimental candidate source** over that interior: it works from its own checklist-derived gap set and, for functions that reach LLM review, forms a hypothesis and may invoke an applicable analyser. Neither a hypothesis nor a sweep is guaranteed per function — triage and prefilter can short-circuit to `clean` first. Wire it in the **generator seat only**, and read the whole contract in "Mapping to RAPTOR's machinery" before using any of its output.

Track which (altitude × slice) cells you've covered. The point of "start with the whole, then file by file, then functionality, then function" is that you sweep the whole grid, not one band.

Component inventory first — the completeness gate (MANDATORY)

Before round 1, enumerate the **entire** project as a flat list of components — every top-level module, package, service, transport, and deployable unit — not just the subsystems that look interesting. For a multi-module build, list every module directory (`ls modules/`, every Maven `pom.xml`, every top-level source package). This inventory is the **denominator** for coverage.

Then maintain a **coverage matrix**: every component maps to a hunt cell — now, or a *named, logged* later round. The hunt is not "done", and the report must not read as done, until **every component is either covered or explicitly listed as omitted with a reason** (out of scope, build-time-only tool, generated code, third-party vendored copy). Silent omission is the exact failure this gate prevents: slicing by hot-spots and quietly skipping whole modules (transports, databinding, the newer/less-audited modules) is how a *shallow* audit masquerades as a complete one — especially on a mature project that has had many issues over the years, where the unexamined module is often where the next bug lives.

Rules:

• The per-round slices must be drawn **from** the full inventory; you may prioritise, but every

component not yet assigned to a cell is recorded as `UNCOVERED` in `TRIED.md` — **never absent from it**.