Bug Bounty Hunting Prompts: a phase sequence for evidence-first web bounty work

A prompt pack, and the README says plainly what is missing

The repository holds reusable prompt files for building a structured, evidence-first web bug bounty hunting workflow, and the second paragraph of the README is the part to read before anything else.

The prompts are adapted from a private hunting workflow. The repository does not contain the original helpers, browser fleet, proxy or email services, dashboard, proof-of-concept runtime, credentials, private operating rules or reference corpus. The prompts are intentionally not runnable without adapting those dependencies to your own environment.

That sentence defines the whole product. What you get is the sequence and the reasoning; what you do not get is anything executable. There is no package to install, no service to configure and no account to create.

The README is unusually explicit about support too. This prompt pack is provided as-is, without setup, integration, debugging or usage support. The maintainers will not provide the private helpers, infrastructure, accounts, RAG corpus, orchestration services or equivalent replacements used in their own workflow. Users are responsible for adapting the prompts, supplying their own tools and resources, validating results, and operating within their own authorization and program rules. Please do not expect maintainers to reproduce private environments or answer individual implementation questions.

That is an unusual level of candour for a published repository, and it is worth internalising before you commit time to it. You are adopting a document, and you are expected to do the engineering.

The repository itself is small in file terms. The top level holds .gitignore, ADAPTATION.md, LICENSE, README.md, SECURITY.md and a phases/ directory. The primary language is recorded as unknown, which is consistent with a repository of Markdown files. The licence is MIT, the homepage is mdpsec.com, and the last push was on 2026-10-03.

Fifteen phases, and the branching structure is the design

The public release contains a sequence of phase files, and the numbering carries information. The table in the README runs from phase 0 to phase 10, but with letters on two of them.

Phase 0 is phase-00-recon.md, described as a lightweight surface map. Phase 1 is phase-01-access.md, for account setup and authenticated access. Phase 2 is phase-02-sweep.md, a broad endpoint and vulnerability-class sweep. Phase 3 is phase-03-closeout.md, which validates the sweep handoff and releases resources.

Then the numbering splits. Phase 4a is scope-only context, and 4b is an authenticated browser walk. Phase 5a is scope-only context for the critical hunt, and 5b is the critical-impact hunting stage. The pattern is clear once you see it twice: the lettered scope-only files exist so a phase can be run with the scope loaded but without the heavier machinery, which is what makes the workflow usable against a target where you hold only partial access.

The tail of the sequence is about independent verification rather than finding. Phase 6 is initial triage and deduplication, phase 7 is validate and escalate, phase 8 is independent verification and escalation, and 8a is one read-only pre-gate escalation pass. Phase 9 is an independent live triage gate, and phase 10 is a same-program duplicate convergence check.

Two branches are deliberately absent. The README states that the duplicate second critical branch and the duplicate second independent escalation branch are not included in this public sequence, and that the browser-walk phase remains available as an optional browser-focused stage.

So the pack is not a linear run of fifteen steps. It is a core path with two branch pairs where the public release keeps one side, and one stage you can drop.

ADAPTATION.md is the replacement index, and it is the entry point

The README points new users at one file first: ADAPTATION.md, which it calls the replacement index for every private integration represented by a YOUR_* variable or an angle-bracket placeholder.

That framing tells you how the prompts are written. The prompts were extracted from a working system, so they contain references to helpers, fleets and services that are not in the repository. Rather than strip those references out and hand you something generic, the author left the placeholders visible and published a file that maps each one to whatever you use instead.

The README reinforces the intent in the same paragraph: do not paste credentials, cookies, tokens, API keys or private infrastructure details into these prompt files. That is both a security instruction and an acknowledgement that the adaptation step is where you would be tempted to leak things.

The placeholder convention is worth understanding as a design choice. A prompt file that says YOUR_BROWSER_LEASE tells you that the step needs a browser session but leaves the mechanism to you. A prompt file that named a specific tool would be less adaptable and would date faster. The cost of the choice is that you have to do the wiring yourself, and the reward is that the prompts stay readable once you have read the index.

The repository also carries SECURITY.md at the root, separate from the README, and the README's safety section points to reporting findings through the program's responsible disclosure channel. Two governance documents alongside the prompt files is a reasonable amount of scaffolding for a security artefact.

One phase at a time, and the handoff artifacts are the contract

The usage section explains that these are prompt source files, not an application or orchestration engine, and then gives a typical adaptation as five steps.

Choose the phases that match your workflow. Replace the runtime variables and integration commands listed in ADAPTATION.md. Supply current target scope, researcher-owned accounts and local evidence paths at runtime. Provide your agent with one phase at a time and preserve the phase handoff artifacts it requests. And run only against authorized, in-scope assets, using bounded, non-destructive proofs and restoring reversible test changes.

The third and fourth steps carry the design. Scope, accounts and evidence paths are supplied at runtime rather than baked into the prompts, which is what allows one set of phase files to serve different programs with different rules. And the instruction to feed one phase at a time, preserving handoff artifacts, is what makes the sequence a pipeline rather than a list of independent prompts. Phase 3 exists precisely to validate the sweep handoff and release resources, and phase 6 starts with triage and deduplication. The phases expect to find what the previous one left.

There is no install step to write out here, because there is nothing to install. The way to get the files is to clone the repository or copy the phase files from it, and the way to start is the five-step sequence above.

The safety list is short and worth quoting as a checklist for your own adaptation. Use the prompts only for authorized security research. Do not target real users, submit or publish findings automatically, collect data in bulk, or leave state changes behind. Keep secrets outside the repository, and report findings through the program's responsible disclosure channel.

Trimming the sequence is an explicit feature, not a workaround

The README gives one worked example of removing integrations you do not use, and it is the clearest statement of how modular the pack is.

An unauthenticated workflow can omit account setup, browser leases, email, SMS and authenticated walks while retaining the recon, sweep, triage and reporting principles.

That sentence names five separate integration points in a single line. It tells you the original workflow leaned on researcher-owned accounts, browser leases for authenticated state, email and SMS for verification and authenticated browser walks for stateful checks, and that all of that is separable from the phases that matter for a black-box assessment.

The same pattern shows in the phase structure. The scope-only context files at 4a and 5a exist as lighter variants of their siblings, and the browser-walk phase is optional. Taken together, the pack is designed to be cut down to what a given engagement permits.

That is the property that makes it more useful than a single long prompt. A workflow that assumes everything is available will stall the moment a program forbids account creation or bulk requests, whereas one that names its integrations as separable lets you drop them and keep the ordering, the triage discipline and the escalation checks.

One thing the pack does not include is any reference corpus. The README lists the reference corpus among the private things withheld, alongside the RAG corpus mentioned in the support section. So there is no example finding, no seeded target and no worked case to check your adapted prompts against.

Where this prompt pack is the wrong tool

The first wrong-tool case is a researcher without web testing experience. The phases assume you can judge what a surface map should contain, what a sweep result means and whether a candidate finding is a real bug or a false positive. The files do not teach those judgements, and with the reference corpus withheld there is no worked example to learn from. Someone who would be helped by a tutorial gets a sequence of instructions that assume the tutorial already happened.

The second case is a team expecting a workflow engine. The README says twice over that these are prompt source files and not an application or orchestration engine. There is no runner, no state machine, no scheduler and no artifact store. If you want a pipeline that executes phases unattended, you are writing that pipeline, and the prompts are just its payload.

The third case is a programme with strict automation rules. The prompts describe a workflow that includes sweeping a broad endpoint and vulnerability-class surface, and the README's own rules forbid collecting data in bulk and forbid targeting real users. A programme whose policy forbids any form of automated enumeration is not compatible with the sweep phase regardless of how carefully you configure it.

There is also a support boundary to plan around. The maintainers will not answer individual implementation questions, so every question you have about adapting a phase has to be answered by reading the phase and by reading ADAPTATION.md. For a solo researcher that is manageable. For a team intending to standardise on this pack, it means the internal knowledge has to live somewhere else.

And the maintenance question is real. The repository has no GitHub releases, so there is no version to pin and no changelog to diff against. The last push was on 2026-10-03, and the README describes the pack as a reference prompt pack that is expected to evolve as hunters adapt it to different agents, tools and program rules. The MIT licence lets you fork and version it yourself, and given that the files are the product, forking is probably the sensible first step if you need stability.

Editorial conclusion

This prompt pack suits a researcher who already knows how to run web tests and wants a written sequence to hand to an agent, since the phase boundaries and the handoff artifacts are the useful part. It does not suit someone starting out, because the phases assume reconnaissance and validation skills the files do not teach, and it does not suit a team expecting an installable workflow, since the README states the prompts are intentionally not runnable without adapting private dependencies. Before adopting, read ADAPTATION.md end to end and count the YOUR_* variables you have to fill, then check SECURITY.md and the repository's own rule about running only against authorized, in-scope assets.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mdpsec/bug-bounty-hunting-prompts on GitHub
4. Project website
5. README