Recon Triage

recon-triage

Overview

Recon tools produce volume; hunters need focus. Given the output of enumeration tools (resolved subdomains, an httpx table of live hosts with tech/status/ports), this skill triages it: which hosts deserve manual attention first, and why.

This is deliberately not a tool runner. It does not run subfinder or httpx — running a tool is a shell command, not a skill. The value here is the judgment layer applied to output the user already has: turning 400 hosts into "look at these 6 first, here's the reasoning."

Anti-Hallucination Rule (Critical)

Triage only the hosts present in the provided input. Do not:

• Invent hosts, subdomains, endpoints, technologies, or versions not in the data.
• Assume a host runs software the input doesn't state.
• Claim a vulnerability exists — this skill prioritizes attention, not findings.

The output is "worth looking at because X", never "this is vulnerable."

If the input is empty, malformed, or too sparse to triage, say so and ask for the actual tool output. Never pad the list to look thorough.

Input

The raw output of the user's recon tools — for example:

• A plain list of subdomains (from subfinder/amass/assetfinder).
• An httpx table: host, status code, title, tech stack, content-length, port.
• Any similar host/endpoint inventory the user pastes.

If the format is unusual, ask what the columns mean rather than guessing.

Triage Rubric

Rank hosts by how likely they are to hide something, using signals actually present in the data:

| Signal | Why it's interesting | |--------|---------------------| | Non-prod naming (dev, staging, uat, test, qa, internal) | Weaker auth, debug modes, older code | | Admin / internal tooling (admin, jenkins, grafana, jira, vpn) | High-value, often mis-scoped | | Unusual tech / outdated versions (when the data states a version) | Known-CVE surface | | Odd status codes (401/403 on interesting paths, 500s) | Auth boundaries, error leakage | | Non-standard ports | Forgotten services, admin panels | | One-off outliers (a host unlike its siblings) | Shadow IT, misconfig | | Default titles ("Welcome to nginx", framework defaults) | Unfinished/forgotten deploys |

Down-rank: CDN/marketing pages, static asset hosts, obvious redirects to the apex, and hosts with no distinguishing signal.

Output Format

Lead with a short prioritized shortlist, then the reasoning:

Top targets to look at first:
1.  — 
2.  — 
...

Lower priority / likely noise:
-  — 

Notes: 

Keep the shortlist tight (typically 5–10). If everything looks like noise, say that honestly rather than manufacturing interest.

Common Mistakes

• Inventing detail. Saying a host "likely runs an old WordPress" when the

input never mentioned WordPress. Only reason from what's there.

• Claiming vulnerability. "This is exploitable." No — the output is

priority, not a finding. Frame as "worth checking because…".

• Ranking everything. A triage that flags 200 of 400 hosts isn't triage.

Be selective; the point is focus.

• Ignoring the boring-but-right. Sometimes the interesting host is a plain

api. subdomain — don't over-index on flashy names at the expense of obvious attack surface like APIs and auth endpoints.

Continuity (session log)

Bug-bounty work spans sessions. If a local engagement log for this program exists (notes/.md in your working directory — gitignored, one file per program), read it first so you build on earlier triage instead of repeating it, then append this run's shortlist and the signal behind each host. Only read a log that's actually present — never invent past history.

Ethics

Prioritizing attack surface assumes the hosts are in an authorized program. If a host looks out of scope, flag it — pair with scope-check before testing.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: amansingh909
• Source: amansingh909/claude-bounty-skills
• License: MIT

Install and usage instructions live in the source repository linked above.