writing-vuln-reportslisted

# Writing vulnerability reports A finding that isn't clearly reported doesn't get fixed. The job of a report is to move a specific defect from your head into the maintainer's, with enough proof that they can reproduce it in minutes and enough impact that they prioritize it, and nothing else. This skill turns a schema-shaped finding into that report. ## When to use - A finding is `confirmed` (see [FINDING-SCHEMA.md](../../FINDING-SCHEMA.md)) and you're writing it up for a human: bounty submission, advisory, ticket, email. - You have several findings and need consistent, triager-friendly writeups. ## Scope check Only report findings from authorized testing, to the party entitled to receive them (the program's channel, the maintainer's security contact, your client). Don't disclose someone else's data or a third party's system you weren't scoped to touch. When in doubt about the channel, ask before sending - a report is outward-facing and hard to unsend. ## The structure that gets findings fixed Lead with impact, prove it fast, make the fix obvious. Sections: 1. **Title** - the specific defect and where. "IDOR in `admin_bulk_delete` lets any user delete any post," not "Access control issue." 2. **Summary** (2 to 3 sentences) - what the bug is, who can trigger it, what they get. A busy triager should grasp severity from this alone. 3. **Impact** - the concrete consequence, tied to the target's threat model. Who is harmed, what they lose, what precondition is ne