Bug Report Skill

A bug report is only useful if someone else can reproduce it. The best ones are precise: an exact title, numbered steps, what you expected vs. what happened, and the environment it happened in. This skill turns a vague "it's broken" into a ticket a developer can act on immediately — no clarifying round-trips.

Working from a brief

Given "the export button doesn't work", write the full report anyway — infer the likely repro steps, expected behaviour, and environment, marking inferences (confirm). Keep facts (what was observed) separate from guesses (likely cause). Never invent logs/errors; flag them to attach.

Required Inputs

Ask for these only if they aren't already provided (else infer and label):

• What's wrong — what you did, what happened, and what you expected instead.
• Steps to reproduce — the exact sequence (and whether it's consistent or intermittent).
• Environment — device, OS, browser/app version, account/role, and any relevant data state.
• Evidence — screenshots, a screen recording, console/network errors, logs, request IDs.

Output Format

Bug Report

• Title — a precise one-liner: what's broken + where + the key condition ("Export to CSV fails for >1,000 rows on Safari").
• Severity / Priority — impact (blocker/critical/major/minor) and how widespread, kept distinct from urgency.
• Environment — device/OS/browser+version, app/build version, account/role, region/data as relevant.
• Steps to reproduce — numbered, exact, starting from a known state; note frequency (always / ~X% / once).