bug-bounty-report-writer

Bug Bounty Report Writer v4.0

The difference between a $500 report and a $50,000 report is almost never the vulnerability itself — it's the quality of the writeup. Triagers at top programs read hundreds of reports a week. A report that clearly shows impact, provides a working PoC, and quantifies business risk gets escalated fast. One that doesn't gets marked "informational" or "out of scope."

This skill produces that first kind of report.

---

First Step — Always Load the Reference

Before generating any report, read references/vickie-li-bootcamp.md. It contains the 8-step framework by Vickie Li (Bug Bounty Bootcamp), escalation paths for every major vuln class, and the exact writing principles that separate top-tier reports from dismissed ones. This takes 2 minutes and directly improves every section you write.

Also load the other references as needed:

• references/cvss4-guide.md — for scoring the vector
• references/impact-templates.md — for quantified business impact numbers
• references/exploit-templates.md — for ready-to-run exploit code

---

⚡ PRE-REPORT VERIFICATION — Run This FIRST, Every Time

Before writing a single line of the report, execute all 5 checks below in order. Output a Verification Report as a collapsible summary block. If any check FAILS with HIGH confidence, flag it and ask the user to clarify before proceeding. If it's LOW confidence or ambiguous, flag inline and continue.

---

CHECK 1 — 🔍 Hallucination Detector

Verify every factual claim in the user's input against what can be reasonably confirmed:

Endpoints / Functions

• Does the endpoint pattern match the target's known technology stack? (e.g., /api/v2/users on a Rails app vs /graphql — does it fit?)
• Does the parameter name make sense for the vuln type claimed?
• If the user claims a specific function name (e.g., eval(), deserialize()), is it plausible for the described framework?
• Flag as [UNVERIFIED_ENDPOINT] if the endpoint looks invented or inconsistent.