domains / families / security / hunt-dispatch

hunt-dispatch

combined

Skill-set loader for /hunt orchestrator. Skill-set loader for /hunt orchestrator. Fingerprints the target, picks the right platform attack skills, and loads the Red Team or WAPT skill set. Use when /hunt has just received a mode answer (redteam or wapt + blackbox|greybox) and needs to load the appropriate skills and print the taxonomy. Not for direct user invocation.

When to use

• You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.
• You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.

When not to use

• Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.
• Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.
• Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.

Skill page

Conflict

Both copies implement the same /hunt skill-set loader (fingerprint hosts, map signals to platform skills, load a bounded set). They overlap heavily on the invocation contract, the fingerprint loop, and the signal-to-skill table. However, each contains material steps the other lacks: the uphiago copy defines the tiered priority order, the 8-skill load budget, and de-dup rules (CDN-only, cloud header vs leaked key, framework vs class), while the sickn33 copy adds a mandatory 404 baseline step (soft-404 control via status/size/hash) and an engagement-context/authorization gate. Crowning one would hide the other's real alternative procedure, so they should be combined.