hunt

/hunt

slim two-track dispatcher. one mode question, one branch, delegate.

engagement frame — state once, then proceed. invoking /hunt asserts the operator holds written authorization to assess the named scope: a bug-bounty program's in-scope assets, a signed engagement letter, infrastructure they own, or a practice target. work stays inside that scope — an out-of-scope host stops the run rather than widening it. the deliverable is a reproducible, remediable finding.

do not prompt for this and do not ask about the SOW. it is an assertion the operator already made by invoking the command; restating it once keeps the engagement context explicit for the rest of the session instead of leaving it implied.

step 0 — parse

target.com               single target
*.target.com             wildcard — /recon <base> first, then hunt each live host
targets.txt              multi-target — mode question once, applied per line
--vuln-class <X>         skip mode question, load only hunt-<X>
--source-code <p|url>    static + dynamic
--chrome                 browser MCP mode

wildcard handler: if $TARGET begins with *., strip prefix and invoke /recon <base> before continuing.

step 1 — mode dispatcher

skipped if --vuln-class is set.

question: "what kind of engagement is this for {target}?"
header:   "engagement"
options:
  1. Red Team Assessment   — critical/high impact, chained findings, client deliverable
  2. WAPT / BugHunting     — full OWASP coverage, platform/program report

do not prompt the operator to paste a SOW, scope-of-work, or engagement-letter document — that is sensitive client data and must not be ingested or persisted. This is a data-hygiene rule, NOT an authorization bypass: scope is still enforced by /scope (deterministic, deny-wins) and the triage-validation 7-Question Gate before any finding ships. Authorization is assumed to be established out-of-band; the bundle verifies in-scope, it does not collect proof-of-authorization paperwork.