Bug report writer

Purpose

Turn a rough defect observation into a structured, reproducible bug report that a developer can act on without a follow-up conversation — with a clear title, exact reproduction steps, environment details, severity/priority ratings, and an impact statement that helps triage prioritize correctly.

When to Use

Invoke this skill when the user asks to:

• Write or clean up a bug report or defect ticket
• Log an issue found during QA, UAT, or exploratory testing
• Convert a vague "it's broken" complaint into an actionable ticket
• Standardize how their team documents defects in JIRA or a similar tracker
• Assess the severity, priority, or business impact of a defect
• Document reproduction steps for an intermittent or hard-to-reproduce issue

Inputs Required

Before starting, collect:

• What went wrong: The observed behavior — what the user saw or experienced
• Expected behavior: What should have happened instead
• Reproduction context: What the user was doing when it occurred (URL, feature, action sequence)
• Environment: Browser/OS/device, app version or build, environment tier (prod/staging/dev)
• Frequency: Always / Intermittent / Once — and any pattern noticed
• User/account context: User role, account type, or data state relevant to the bug
• Evidence available: Screenshots, screen recordings, console logs, network traces, error messages

If reproduction steps or environment details are missing, reconstruct the most likely sequence from the description and flag each assumption explicitly as "Assumed — confirm."

Instructions

Step 1: Write a Precise Title

Format: [Area/Component] Concise symptom when specific condition

• Lead with the affected area in brackets, then the symptom, then the trigger condition
• Describe the symptom, not the suspected cause (you don't yet know the cause)
• Keep under 12 words; make it scannable in a backlog of 200 tickets
• Good: [Checkout] Apply-coupon button unresponsive on Safari mobile
• Weak: Coupon bug / Something wrong with checkout

Step 2: Write the Summary

Two to three sentences answering: what breaks, where, and who it affects. This is what a triage lead reads before opening the full ticket. State the defect factually — no speculation about the underlying code.

Step 3: Document Steps to Reproduce

Numbered, atomic, one action per step. A developer with no context should reproduce it on the first attempt.

• Start from a known state (e.g., "Logged in as a standard user on the dashboard")
• One user action per numbered step — no compound steps
• Include specific data used (coupon code, input values, file names)
• End with the exact step where the defect appears
• If intermittent: note reproduction rate (e.g., "Occurs ~3 of 5 attempts") and any conditions that increase likelihood

Then separate into two labeled fields:

• Expected Result: What should happen after the final step
• Actual Result: What actually happens, including exact error text if any

Step 4: Build the Environment Table

Render as a two-column table:

Omit rows only if genuinely irrelevant to the defect type.

Step 5: Assess Severity and Priority

Rate both separately — they are not the same thing.

Severity (technical impact):

• S1 – Critical: Crash, data loss, security exposure, or complete feature blockage with no workaround
• S2 – Major: Core function broken; workaround exists but is painful
• S3 – Minor: Non-core function broken or degraded; easy workaround
• S4 – Cosmetic: Visual/text issue with no functional impact

Priority (business urgency):

• P1 – Urgent: Fix now; blocks release or affects revenue/many users
• P2 – High: Fix this sprint
• P3 – Medium: Fix when capacity allows
• P4 – Low: Backlog

State one sentence of reasoning for each rating. A cosmetic bug on the checkout button can still be P1 if it kills conversions — call that out.

Step 6: Write the Business Impact Statement

Two to three sentences: who is affected, how many (or what proportion), and the consequence if unfixed (revenue, support load, compliance, reputation). This is the field that moves a ticket up the queue — make it concrete, not "users are frustrated."

Step 7: Summarize Evidence

List each piece of available evidence and what it shows. For each: filename/link placeholder + one line describing what it demonstrates. If a key piece of evidence is missing (e.g., no console log for a suspected front-end error), note it under Evidence Gaps with what to capture next.

Output Format

• Structure: A single JIRA-ready ticket with clearly labeled fields in the order below
• Length: 300–500 words
• Format: Structured document — bold field labels, numbered reproduction steps, one markdown table for environment
• Sections: Title → Summary → Steps to Reproduce → Expected Result → Actual Result → Environment (table) → Severity & Priority (with reasoning) → Business Impact → Evidence Summary → Evidence Gaps (only if gaps exist)
• Tone: Neutral, factual, developer-facing — no blame, no speculation about root cause, no filler

Quality Checklist

Before delivering output, verify:

• [ ] Title follows the [Area] symptom when condition format and is under 12 words
• [ ] Every reproduction step is a single atomic action, numbered, starting from a known state
• [ ] Expected Result and Actual Result are stated as separate, contrasting fields
• [ ] Environment table includes app version and environment tier (not left blank without a flag)
• [ ] Severity and Priority are rated separately, each with one sentence of reasoning
• [ ] Any reconstructed or missing detail is explicitly labeled "Assumed — confirm" or listed under Evidence Gaps

Notes

• Severity ≠ Priority is the most common error in bug reports — a low-severity cosmetic issue in a high-traffic conversion path can be high priority. Always rate both independently.
• The single biggest cause of "cannot reproduce" bounces is compound reproduction steps and missing starting state — atomic steps from a known state fix most of them.
• For intermittent bugs, reproduction rate and triggering conditions are worth more than a perfect step sequence — capture the pattern, not just the failure.
• Keep root-cause speculation out of the report entirely; describing symptoms accurately lets the developer investigate without being anchored to a wrong theory.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

• ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
• <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

1. Drag this file into a new chat, or copy and paste its contents
2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills