testland/bug-report-template
Use for any question or task about bug reports, including what makes a good one, turning an informal complaint or a CI failure (JUnit XML, Allure, pytest or Playwright output) into a report, and reports closed as cannot reproduce. Fills summary, environment, steps, expected vs actual and severity rationale, then checks each field is usable.
87%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
severity-and-priority-scales.mdreferences/
Severity and priority classification scales
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 - intrinsic impact
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 - extrinsic business order
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. |
The two are independent
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.