Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Bug report generator

Transforms raw, unstructured issue descriptions into complete, developer-ready bug reports with reproduction steps, environment details, expected vs. actual behavior, severity/priority classification, and an evidence…

download .md

Purpose

Convert a rough issue description into a fully structured, unambiguous bug report a developer can act on immediately — with numbered reproduction steps, expected vs. actual behavior, environment data, severity and priority classification, and a required-evidence checklist. Eliminates the back-and-forth caused by incomplete tickets.

When to Use

Invoke this skill when the user asks to:

  • Turn a raw issue note or user complaint into a proper bug report
  • File a bug in Jira, Linear, GitHub Issues, Azure DevOps, or a similar tracker
  • Standardize or clean up an incomplete bug ticket
  • Write reproduction steps for a defect they've observed
  • Assign severity and priority to a reported issue
  • Batch-format multiple raw defect notes into consistent tickets

Inputs Required

Before starting, collect:

  • Raw issue description: The unstructured account of what went wrong (paste-as-is is fine)
  • Where it happened: The feature, page, screen, or workflow affected
  • Environment: OS, browser/app version, device, and build/release number if known
  • Steps observed: Whatever the reporter did before the issue appeared (even if fragmentary)
  • Expected result: What should have happened (infer if not stated, and flag the inference)
  • Impact: Who is affected and how badly (blocks work / annoying / cosmetic)
  • Evidence available: Screenshots, screen recordings, logs, console errors, or none

If environment, expected result, or evidence is missing, produce the report with clearly marked "Unknown — needs confirmation" placeholders in those fields rather than guessing silently.

Instructions

Step 1: Parse the Raw Input

Extract the core facts from the unstructured description:

  • The trigger: What action or condition surfaced the bug
  • The symptom: What visibly or functionally went wrong
  • The scope: One user, some users, all users, or unknown
  • Anything ambiguous: List gaps that need confirmation rather than inventing details

Do not invent reproduction steps, error messages, or version numbers. If a detail isn't in the input, mark it as needing confirmation.

Step 2: Write a Clear Title

Format: [Area] Concise problem statement — condition

  • State the symptom, not the guessed cause
  • Include the affected area in brackets
  • Keep under 100 characters
  • Good: [Checkout] Apply Coupon button unresponsive on mobile Safari
  • Weak: Coupon broken or Bug in checkout maybe caching issue

Step 3: Build Reproduction Steps

Write numbered, deterministic steps a stranger could follow:

  1. Start from a known state (logged in as X, on page Y)
  2. One discrete action per step
  3. Include exact input values, button labels, and menu paths
  4. End at the step where the defect appears - Add Reproducibility: Always / Intermittent (X of Y attempts) / Once / Unknown - If steps can't be confirmed from the input, write "Steps unconfirmed — reporter did not specify" and list the partial sequence available

Step 4: State Expected vs. Actual Behavior

  • Expected: What should have happened, one sentence
  • Actual: What did happen, one sentence — factual, no speculation about root cause
  • Keep these parallel so the gap is obvious at a glance

Step 5: Capture Environment

Structure as a labeled block:

  • OS / Device: e.g., iOS 17.4, iPhone 14
  • Browser / App version: e.g., Safari 17.4 / App build 3.12.0
  • Build / Release: e.g., staging build #4821
  • Account / Role: e.g., Free tier, admin, logged-out Mark any unknown field as "Unknown — needs confirmation."

Step 6: Classify Severity and Priority

Assign both independently.

Severity (technical impact):

  • S1 — Critical: Crash, data loss, security exposure, or core workflow fully blocked with no workaround
  • S2 — Major: Key feature broken, but a workaround exists
  • S3 — Minor: Feature partially works or a non-core function is impaired
  • S4 — Cosmetic: Visual, copy, or polish issue with no functional impact

Priority (business urgency):

  • P1 — Now: Affects many users or revenue/compliance; fix this cycle
  • P2 — Soon: Affects some users or an important workflow; schedule next
  • P3 — Later: Limited impact; backlog

State a one-line rationale for each rating tied to the impact input.

Step 7: Attach the Evidence Checklist

List required and available evidence:

  • Screenshot of the error state — attached / needed
  • Screen recording of the repro — attached / needed
  • Console or network error — attached / needed
  • Server/application logs with timestamp — attached / needed
  • Sample data or affected record ID — attached / needed Flag any high-severity report missing evidence as "Blocker for triage."

Output Format

  • Structure: A single filable bug ticket with labeled sections in ticket order
  • Length: 250–450 words per report
  • Format: Structured document — bold field labels, numbered repro steps, block-formatted environment
  • Sections: Title → Summary (1–2 sentences) → Steps to Reproduce → Expected Behavior → Actual Behavior → Environment → Severity & Priority → Evidence Checklist → Open Questions
  • Tone: Factual, neutral, developer-facing — no blame, no speculation about cause, no filler

Quality Checklist

Before delivering output, verify:

  • [ ] Title states the symptom with the affected area in brackets and is under 100 characters
  • [ ] Every reproduction step is a single discrete action with exact labels/values
  • [ ] Expected and Actual behavior are both present and phrased as a parallel contrast
  • [ ] Severity and Priority are each assigned with a one-line rationale
  • [ ] No invented details — every unconfirmed field is explicitly marked "Unknown — needs confirmation"
  • [ ] Open Questions section lists any gaps that block triage

Notes

  • Severity and priority are not the same axis — a cosmetic bug on the pricing page can be low severity but high priority; keep them independent.
  • The most common failure mode is repro steps that assume context; always start from a fully known state.
  • For batch input, produce one complete report per issue rather than merging distinct defects into a single ticket.
  • If the raw input describes multiple unrelated problems, split them and note "Split from combined report" in each Open Questions section.

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