Bug Hunting — Router

This is the entry point only. It does not contain technique detail — it decides which domain guide to load, then gets out of the way. Loading this file should never cost more than a few hundred tokens.

The core discipline

Real bug hunting is not "run the checklist for one vuln class." Nobody tells you what bug exists, or if one exists at all. The loop is:

1. Map the surface completely — every endpoint, param, auth state, response shape.
2. Hypothesize widely — for each input, ask "what could this become?" Don't commit to one guess. A URL-fetching param could be SSRF, or IDOR if that value doubles as a record key — keep both alive until evidence rules one out.
3. Confirm, don't guess — a finding is only real once you've proven it (differential response, out-of-band callback, reproduced twice). Report only what you proved.

Step 0 — the operating workflow (mandatory, before any domain routing)

Before picking a domain, load methodology/workflow.md and follow it. This is not optional technique reference — it's the administrative discipline that separates a systematic hunter from someone with the same knowledge who doesn't organize it: a real per-target working folder (scope.md, recon/, hypothesis-log.md, findings/, session-notes.md), a hard gate that blocks exploitation until recon is actually marked complete, a running log of every hypothesis tried (so nothing gets re-tested or lost across a long session), and a resume record so a paused engagement doesn't restart from zero.

If resuming a target already worked on, methodology/workflow.md also tells you to read that target's session-notes.md and hypothesis-log.md first — before doing anything else.

Step 1 — identify the target type

Read the target's shape (URLs, app type, what you were handed) and pick the matching domain guide. Load only that guide's ROUTER.md next — not its references/, not another domain.

A single engagement often touches more than one — e.g. a web app backed by an API backed by an LLM feature. Load each relevant domain's ROUTER.md as you reach that part of the surface; don't front-load all of them.

Step 2 — inside a domain guide

Each domain ROUTER.md is a signal table: observable thing about this endpoint → plausible vuln class(es) → how to confirm. It stays small on purpose. Only when it points you at a specific class and you're going deep on that one, pull the matching file from that domain's references/.

Step 3 — always applies, regardless of domain

• methodology/workflow.md — the working-folder/hypothesis-log/resume discipline from Step 0. Referenced again here because it stays active for the whole engagement, not just at the start.
• methodology/mindset.md — the hunter's decision loop in more depth (recon-first, hypothesize-wide, confirm-strict), read once, not per-target.
• methodology/reporting.md — how to write up a confirmed finding so it gets paid, not closed — a finding only moves from the hypothesis log into findings/ once it clears this bar.

Scope discipline

Only test targets you are explicitly authorized to test — an in-scope bug-bounty program, your own systems, or a lab you control. Read the program's scope and rules before sending a single request. This applies regardless of which domain guide is loaded.