hackerone

HackerOne Bounty Scope-Guard Skill

You are executing a HackerOne bug bounty workflow. This Skill is a

scope-guard wrapper: first parse and enforce the program scope and program

rules, then hand each in-scope asset to pentest-flow for the actual

security testing. Never touch an out-of-scope asset at any stage.

The launch argument is a HackerOne program link (<SCOPE LINK>), for example

hackerone.com/<handle> or .../policy_scopes. This Skill has no preset scan

target (requires_target: false in frontmatter); targets are discovered from

the program scope.

Startup and output contract

• Do not load or print the reference document during startup. It contains

report-template material and examples; load it only when preparing a report

or when parsing an ambiguous scope requires it.

• Resolve the supplied program link or obtain a pasted scope before claiming

that scope is defined. Never treat example assets in this Skill or its

references as observed program scope.

• Once scope is confirmed, keep the status concise:

Scope defined: <count> in-scope, <count> out-of-scope. Starting recon on <asset>.

• Automatically begin recon on the first confirmed URL or WILDCARD asset

after you have printed that status in the same workflow that loaded scope.

Do not pause for an asset-selection question unless scope is ambiguous,

contains no directly supported assets, or the user explicitly asks to choose.

• Mid-session user check-ins (e.g. "ready to begin?", "are we ready?") are

not a green light by themselves: answer with scope summary, intended first

asset, and any blockers first. Start or resume recon tools only after an

explicit go-ahead or a clear recon/pentest command.

• Do not print raw HTML, full reference text, or raw tool output. If scope cannot

be loaded, ask the user to paste the Scope tab and stop before testing.

• Never treat hackerone.com as the recon/pentest target. The program link is

only a discovery seed. Do not run js_recon, dir_enum, subdomain_enum, or

attack tooling against HackerOne itself.

Phase 1: Read scope

1. Call hackerone_scope first (required)

• Immediately call: hackerone_scope(program="<SCOPE LINK or handle>").
• This tool queries HackerOne public GraphQL and returns structured in-scope

and out-of-scope assets. Use it even if a prior HTML fetch showed an empty SPA shell.

• Do not reverse-engineer HackerOne JavaScript bundles, dump /assets/static/*,

or run js_recon on hackerone.com/* to discover the GraphQL endpoint.

1. Fallback only if hackerone_scope fails

• Optional one-shot GET of the program page is allowed only as diagnostics;

an empty SPA shell is normal and not a scope source.

• Ask the user to paste the in-scope and out-of-scope tables from the program

page Scope tab. Provide this example format:

     In scope:
     https://api.example.com        | URL       | Eligible for bounty
     *.example.com                  | WILDCARD  | Eligible for bounty
     app.example.com                | URL       | In scope, NOT bounty-eligible
     com.example.android            | GOOGLE_PLAY_APP_ID | Eligible for bounty

     Out of scope:
     blog.example.com               | URL
     *.corp.example.com             | WILDCARD

1. Parse leniently

• Extract two lists from the tool result or paste: in-scope and

out-of-scope.

• Recognize asset types by human label or API enum:

URL, WILDCARD (*.x.com), CIDR/IP, SOURCE_CODE,

GOOGLE_PLAY_APP_ID/APPLE_STORE_APP_ID/TESTFLIGHT/OTHER_APK/OTHER_IPA,

HARDWARE, AI_MODEL, SMART_CONTRACT, OTHER, and similar values.

• Recognize three eligibility states. Submission eligibility and bounty

eligibility are independent booleans:

• submission=true, bounty=true → in scope, testable, bounty eligible.
• submission=true, bounty=false → in scope, testable, not bounty eligible.

Do not confuse this with out of scope.

• submission=false → out of scope; never test it.
• If parsing is uncertain, ask the user to confirm. **Never default an

uncertain asset to in-scope.**

1. Record the boundary internally

• Keep the in-scope assets with their type and eligibility available to the

workflow.

• Keep an out-of-scope deny-list for enforcement throughout the run.

Phase 2: Enforce boundaries

Before any testing begins, state and follow these hard rules throughout:

1. Scope boundary

• Test only assets in the in-scope list.
• Never touch an asset on the out-of-scope deny-list: do not fetch it, scan

it, or send any payload to it.

• pentest-flow may directly handle only URL and WILDCARD assets. Other

types (mobile apps, source code, CIDR, hardware, and so on) are not

automated; ask the user to confirm how they should be handled.

1. Program rules (in addition to VulnClaw's existing BLOCKED_PATTERNS and

RESERVED_IP_RANGES)

• No DoS or availability impact: prohibit stress tests, resource

exhaustion, and high-volume concurrency.

• Respect rate and automation limits: operate slowly and serially, and

follow any program rule that prohibits automated scanning.

• No social engineering: do not target or phish people.
• Minimal impact and no PII exfiltration: stop once a vulnerability is

verified; do not export real user data or perform destructive actions.

1. Handle exceptions safely

• If any step could cross the scope boundary or violate a program rule,

stop and ask the user.

Phase 3: Enumerate and confirm

1. Use the concise startup status from the output contract and select the

first directly supported asset automatically.

1. Ask which asset to start with only when the output contract requires it.
2. Handle one asset at a time and confirm each one separately. Avoid

concurrency that could cross the scope boundary or trigger rate limits.

Phase 4: Delegate to pentest-flow

For the selected single in-scope asset:

1. Treat that asset as the active target. Run the full

recon → vulnerability-discovery → exploitation workflow against it, not

against the HackerOne scope link.

1. Stay within scope throughout. Exclude and report any newly discovered

subdomain or endpoint that is outside the in-scope definition, especially

one that does not match an in-scope WILDCARD.

1. Continue to enforce all Phase 2 program rules.

Phase 5: Report in HackerOne format

For every confirmed finding, produce a report in HackerOne submission format:

1. Title — concise description of the vulnerability, including its type and

affected asset.

1. Asset — the affected in-scope asset (URL or identifier).
2. Severity (CVSS) — CVSS vector and score (Critical/High/Medium/Low).
3. Steps to Reproduce — reproducible steps, including requests, responses,

and payloads.

1. Impact — exploitability and business impact.
2. Remediation — recommended fix.

When there are multiple findings, keep each one in a separate section. Include

a parameterized Python PoC using requests when useful.

Remind the user that reports are for manual submission on HackerOne; this

Skill never submits reports automatically.

References

• references/hackerone-report-and-scope.md — scope parsing reference (asset

type ↔ API enum, three-state eligibility, pasted table shapes), mandatory

program rules, and the HackerOne report template.