Pre-bounty: scope recon & target prioritization

The core thesis

Most hunters converge on whatever is cheapest to start testing. That means the crowd is an artifact of the setup barrier, not of where the bugs are. So the edge is systematic: rank the scope by

opportunity ≈ (payout ceiling × freshness) ÷ crowd, with setup difficulty acting as a moat - a hard-to-reproduce environment keeps competitors out, so it is a positive when paired with a high ceiling.

The whole skill exists to compute that ranking from real program data and show it in a way the user can act on. A high max-payout asset that is trivial to set up and already swept (lots of resolved reports) is a worse target than a modest one nobody has tooled up for. Make that legible.

Inputs this skill accepts

Any of, in order of preference:

• A program URL - hackerone.com/<program>, bugcrowd.com/<program>, app.intigriti.com/..., yeswehack.com/..., or a self-hosted /security / security.txt / VDP page.
• A pasted scope table or asset list (domains, mobile apps, repos, APIs).
• A rough description of API/repo access the user already has.

If you only get a program name, construct the URL. If the platform page is JavaScript-rendered (HackerOne, Bugcrowd, Intigriti all are), use the browser tools to read it - WebFetch returns an empty shell for these. read_page / get_page_text on the policy and scope tabs is the reliable path.

Workflow

Work the five stages in order. Stages 1–3 are parallelizable - fire the fetches and searches together.

1. Gather the scope (the signal-richest step)

Pull and record, per asset:

• Asset name, type (domain / mobile / desktop / API / source / other) and whether it is in or out of scope.
• Payout tier - most programs tag assets into tiers (HackerOne Core/Non-core; Bugcrowd P1–P5 targets; others "critical eligible" vs not). Capture the max reward reachable per asset - this is the ceiling.
• Resolved-report count / share per asset if the platform shows it. This is your single best crowd proxy - an asset with 40% of all resolved reports is picked-over; one with <2% is open. HackerOne shows this on the scope table; Bugcrowd/Intigriti show submission stats less granularly (note when missing).
• Last-updated date of each scope entry → freshness. Recently added or rescoped assets have had fewer eyes.
• Program-wide reward table (per-severity bounty ranges + averages) and the severity mix of resolved reports if shown.

See references/sourcing.md for exactly where each platform surfaces these.

2. Mine bug history

• Check the program's hacktivity / disclosed reports. Many programs disclose nothing publicly - say so plainly and fall back to the crowd proxy.
• Web-search public CVEs and researcher writeups for the target's products. The recurring bug class tells you what actually lands (e.g. trust-boundary RCE, config-precedence, deep-link/IPC on native clients). Record specific CVE IDs where found.
• Note remediation / dedup signals - if the policy says a bug class is under a wholesale fix, reports there will close as duplicates. Flag those assets as saturated regardless of payout.

3. Extract the boundary gotchas

The fine print is where hunters waste days. Capture:

• Adjacent in/out pairs - cases where a near-identical bug is in-scope on one asset and out on another (e.g. first-party MCP in-scope vs OSS MCP out; first-party connector in vs third-party-in-directory out).
• Excluded vulnerability classes (DoS, clickjacking on non-sensitive pages, missing cookie flags, dependency confusion, self-XSS, rate-limiting, etc.).
• Platform-standard deviations and payout nerfs - especially "one bounty per systemic issue" and discretionary PII-leak severity, which kill the "report many instances" strategy.
• Testing constraints (e.g. leaked-key "authenticate then immediately deauth only", required X-HackerOne-Handle header / researcher email).

Render this as a compact in ✅ / out ❌ table - see the output spec.

4. Score & rank every asset

Apply the rubric in references/scoring.md. For each asset produce: { setup tier + time estimate, crowd, payout ceiling, freshness, ROI verdict, opportunity score 0–100 }, then sort best→worst. Verdict buckets: Prime · Good · Recon · Skip · Dead. Be honest that the two highest-ceiling assets are often near the bottom because the crowd is already there - surfacing that inversion is the point.

5. Deliver

Produce the artifacts below. Lead with the ranking; it is what the user asked for even when they phrased it as "analyze the scope".

Output spec

The output is tables + the two widgets. Prose is connective tissue, not the product. Put every fact that fits in a cell in a cell - never restate in a paragraph what a table or widget already shows. See "Prose discipline" below for the hard budget; violating it is the most common failure of this skill.

Deliver, in this order:

1. Program header - one line. bounty since · total paid · paid/90d · resolved · response-efficiency · # in-scope assets, then a single sentence on how hunted the program is. No more.
2. Boundary gotchas - a table. The in ✅ / out ❌ adjacent pairs as a two-column table. Follow with at most 3–4 bullets for the strategy-killing nerfs (systemic-dedup, testing constraints, saturated classes) - one line each, no sub-bullets, no paragraphs.
3. Severity economics - a table. Columns: severity · share of resolved · avg bounty · range, one row per severity. Then one italic sentence: "where the crits actually land", grounded in the CVE corpus - noting crit rates are usually ~1% and the money is repeatable Highs.
4. Ranked list widget, best→worst - rank, verdict chip, payout ceiling, setup time, crowd %, freshness, and a one-line "why" per asset. Render with the ranked-list widget in references/sankey.md. The widget carries the per-asset detail; do not narrate the list row by row afterward.
5. Ranked Sankey widget - the three-stage asset → replication setup → ROI verdict flow, assets ordered best (top) → worst (bottom), thread width = report volume, labels carrying payout ceiling + freshness. Fill the one data array in the references/sankey.md template - do not hand-roll new diagram code. Render via the visualize show_widget tool (call its read_me once first, as that tool requires).
6. Verdict - a tight closer under both widgets. Only what the tables can't say: name the top 1–3 picks (one clause each on why now), state the inversion in one sentence (which high-ceiling assets sit at the bottom and why), and flag any technique-development target. Cap this whole section at ~120 words.

Prose discipline (the point of this update)

• Tables and widgets are load-bearing; prose only connects them. If a sentence repeats a number or verdict already in a cell/chip, cut it.
• Budget: header = 1 line; each table gets ≤1 lead-in line and ≤1 follow-up line; the closing verdict ≤120 words. No section is a paragraph block.
• No row-by-row narration of the ranked list - that is the widget's job.
• One sources line at the very end (CVE/writeup links), not inline essays.
• When in doubt, move the sentence into a table cell or delete it.

Notes on judgment

• Estimate, but flag estimates. Setup-time and opportunity scores are your synthesis; the payout ceiling, crowd counts, and dates are hard data from the program. Keep the two visibly separate so the user can trust the spine.
• Scale to the ask. "Quick take on this program" → the ranked list is enough. "Full workup" → all four artifacts plus the CVE history.
• Stay in authorized-recon lane. This skill reads public program data and public vulnerability history to prioritize; it does not test, exploit, or probe live targets. Reproduction/testing happens later, under program rules.
• This skill pairs with a reporting skill for the next phase (filing a found bug). Don't try to do both; hand off.