report-writinglisted

# Report Writing — Professional Vulnerability Disclosure ## When to Use - `/report` command invoked - Validator has issued a CONFIRMED verdict - Director decides to submit a finding - Need to draft a follow-up or clarification to a maintainer ## Writing Principles ### Sound Human, Not AI Reports go to real maintainers. They can spot AI-generated text instantly and will take your report less seriously. **Avoid:** - Starting sentences with "It is worth noting that..." or "It should be noted..." - "This vulnerability allows an attacker to..." (every single sentence) - Bullet-point-only reports with no narrative flow - Overly formal language ("hereby", "aforementioned", "thus") - Repeating the same sentence structure back to back - Hedging everything ("potentially", "could possibly", "might theoretically") - Filler phrases ("in order to", "it is important to", "as a matter of fact") - Numbered lists for everything — use prose where it reads better **Do:** - Write like a competent engineer explaining a bug to a colleague - Vary sentence length — mix short punchy sentences with longer explanations - Use active voice: "The parser accepts..." not "It can be observed that the parser..." - Be direct about impact: "This crashes the process" not "This may potentially lead to a denial of service condition" - Use contractions naturally: "doesn't", "won't", "can't" — especially in emails - Start paragraphs differently — not every paragraph should begin the same way - Include one spec