---
name: bug-report-writer
description: Use this skill whenever the user asks to write a bug report, turn notes into a Jira ticket, clean up a defect, make a bug report clear, summarize a failed test as a bug, draft a defect report, or create a QA issue from rough notes.
---

Take the user's raw input — rough notes, failed test observations, screenshot descriptions, reproduction steps, or a messy bug description — and produce a clear, professional bug report.

## Output structure

Write the report using exactly these sections in this order:

**Title**
One line. Specific and action-oriented. State what breaks, where, and under what condition. Avoid vague titles like "Login doesn't work."

**Summary**
Two to four sentences. Describe the defect in plain language: what the user was doing, what went wrong, and what the impact is. Write for someone who has not seen the raw notes.

**Environment**
Browser, OS, app version, device, or any other relevant context. If not provided, write: Not provided.

**Preconditions**
The state the system must be in before the steps begin. Include account type, data setup, feature flags, or any other required setup.

**Steps to reproduce**
Numbered. Each step is a single, testable action. Start from the earliest reliable point. If the steps are unclear or incomplete in the raw input, write what is known and flag gaps with: [unclear — needs verification].

**Actual result**
What happened. State facts only. No interpretation. Quote error messages exactly if available.

**Expected result**
What should have happened. Base this on the stated or implied requirement. If no requirement is stated, write a reasonable expectation and mark it: [assumed].

**Severity**
Use one of: critical / major / minor / trivial.
- Critical — blocks core functionality or causes data loss; no workaround exists.
- Major — significantly impairs a feature but a workaround is possible.
- Minor — cosmetic or edge-case issue with low user impact.
- Trivial — typo, whitespace, or style inconsistency with no functional effect.

Do not use high, medium, or low. If severity is not provided, suggest one and explain the reasoning in one sentence.

**Priority**
How urgently this needs to be fixed relative to other work. Use: P1 / P2 / P3 / P4. If not provided, suggest one and explain in one sentence. Priority and severity are not the same — a minor cosmetic issue on the home page seen by all users may be P2 even if it is severity minor.

**Evidence**
Screenshots, logs, network responses, video links, or console output referenced in the raw input. List each item. If none were provided, write: Not provided.

**Impact**
Who is affected, how often, and what they cannot do as a result. Be specific: "All users who attempt to reset their password via the email link" is better than "users."

**Suggested owner or area**
The team, component, or code area most likely responsible. If not clear from the input, make a reasonable suggestion and mark it: [suggested].

**Open questions**
List anything that is unclear, missing, or needs to be verified before the report can be considered complete. Write each as a question. If nothing is missing, write: None.

## Rules

- Separate facts from assumptions. Mark assumptions clearly with [assumed] or [suggested].
- If information is missing, write "Not provided" — do not invent details.
- Keep reproduction steps numbered, minimal, and testable. Remove steps that are not needed to reproduce the issue.
- Use clear QA language. Active voice. No buzzwords or filler.
- Return plain readable text by default. If the user asks for a Jira-ready version, format the output in markdown with headers and code blocks where appropriate.