Builds a well-formed bug (defect) report from raw observation notes - fills in summary, environment, steps to reproduce, expected vs actual, and severity rationale. Validates that each field has the load-bearing content reviewers and engineers need to triage. Use when a stakeholder reports a problem informally (chat, email, voice) and the team needs a triageable issue without round-tripping for missing fields.
75
94%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Deep reference for the bug-report-template SKILL.md. Consult when filling the
Severity and Priority fields in Step 5 - the two are scored independently.
Per ISO/IEC/IEEE 29119-3:2021 (incident-report content; cite by stable standard ID - the spec is paywalled at iso.org but the field semantics are widely adopted).
Severity describes what the defect does to the user when it manifests, independent of business prioritization:
| Severity | When to use |
|---|---|
| Critical | Crash / data loss / security breach / business-stopping outage. |
| Major | Important feature unusable; workaround exists but is significant. |
| Moderate | Degraded UX in a non-critical surface; minor data inconsistency. |
| Minor | Cosmetic, typo, label-only issue. |
Priority describes when the team plans to fix:
| Priority | When to use |
|---|---|
| P0 | Drop everything; fix now; usually paired with Severity Critical. |
| P1 | Fix in the current sprint / cycle. |
| P2 | Fix in the next planning cycle. |
| P3 | Backlog; fix opportunistically. |
A Critical-severity bug for one user might be P2 if the user is non-paying; a Minor-severity bug on the marketing homepage might be P0 if launch is tomorrow. Score severity from the defect's impact on the user; let the PM / engineering decide priority from business context.