REPORT WRITING

Impact-first. Human tone. No theoretical language. Triagers are people.

---

THE MOST IMPORTANT RULE

Never use "could potentially" or "could be used to" or "may allow". Either it does the thing or it doesn't. If you haven't proved it, don't claim it.

BAD:  "This vulnerability could potentially allow an attacker to access user data."
GOOD: "An attacker can access any user's order history by changing the user_id
       parameter to the target user's ID. I confirmed this using two test accounts:
       attacker@test.com (ID 123) successfully retrieved victim@test.com (ID 456)
       orders, including their shipping address and payment method last 4 digits."

PERSISTENCE RULE

Every report-writing session must leave a complete finding folder on disk. Save the report draft, pre-submit checklist, references, downgrade counters, and final submission note under findings/<target-or-program>-<bug-class>/. Never rely on terminal or tmux scrollback for content the hunter needs later.

Minimum files:

findings/<target-or-program>-<bug-class>/
├── hackerone-report.md       # or bugcrowd-report.md / intigriti-report.md / immunefi-report.md
├── submission-notes.md       # final checklist, references, caveats, next action
└── evidence/                 # screenshots, curl output, response bodies when available

If bughunter/tools/validate.py already wrote submission-notes.md, append/update it instead of creating a duplicate.

---

TITLE FORMULA

[Bug Class] in [Exact Endpoint/Feature] allows [attacker role] to [impact] [victim scope]