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 →

Defect triage summarizer

Transforms raw, unstructured defect notes into a standardized triage summary with severity classification, user impact assessment, reproducibility rating, root-cause hypothesis, and a recommended escalation path with…

download .md

Purpose

Convert raw defect notes — screenshots described in words, Slack complaints, half-finished bug reports — into a consistent, decision-ready triage summary that assigns severity, quantifies user impact, rates reproducibility, and routes the issue to the right team. Eliminates the back-and-forth that happens when engineering receives a bug they can't act on.

When to Use

Invoke this skill when the user asks to:

  • Triage or summarize a bug report or defect note
  • Clean up a messy or incomplete defect description
  • Assign severity or priority to an incoming issue
  • Decide who a defect should be escalated or routed to
  • Prepare a bug for handoff to engineering or a product team
  • Standardize a backlog of loosely-written defect reports

Inputs Required

Before starting, collect:

  • Raw defect notes: The unstructured description, complaint, or bug report as written
  • Product area / feature: Where the defect occurred (e.g., checkout flow, quiz grading, video player)
  • Environment: Where it was observed — production / staging / specific browser / device / OS if known
  • User type affected: Who hit it (end learner, admin, paying customer, internal user, all users)
  • Frequency signal: How often it's happening (one report, multiple reports, intermittent, every time)
  • Any reproduction steps: If the reporter provided them, even partial ones
  • Business context (optional): Anything that raises stakes (affects revenue, a launch, an SLA, compliance)

If severity, environment, or reproducibility can't be determined from the notes, mark them as "Unknown — needs confirmation" rather than guessing, and list the specific missing detail.

Instructions

Step 1: Extract and Normalize the Facts

Parse the raw notes and separate observation from interpretation:

  • Observed behavior: What actually happened (the symptom)
  • Expected behavior: What should have happened (infer if not stated, and flag it as inferred)
  • Trigger: The action or condition that produced the defect
  • Strip emotional language, duplicate detail, and speculation into a clean factual restatement. If the reporter's speculation contains a useful lead, preserve it under root-cause hypothesis — not as fact.

Step 2: Assign Severity

Classify using a fixed 4-level scale. Choose the highest level that applies:

  • S1 — Critical: Total outage, data loss/corruption, security or privacy exposure, payment failure, or a full block on a core workflow with no workaround. Affects many users or a high-value user.
  • S2 — Major: A core feature is broken or badly degraded, but a workaround exists OR it affects a limited segment. Significant user friction.
  • S3 — Minor: A non-core feature misbehaves, or a core feature has a cosmetic/edge-case flaw. Users can proceed normally.
  • S4 — Trivial: Cosmetic, copy, or polish issue with no functional impact.

State the one-sentence reason the severity landed where it did (which criterion was met).

Step 3: Assess User Impact

Quantify the blast radius using three dimensions:

  • Who: The affected user segment and estimated scope (all users / paying tier / single account / one region)
  • How many: Best estimate from the frequency signal (single report, cluster, widespread)
  • Workaround: Does one exist? If yes, state it in one line. If no, say so — absence of a workaround escalates urgency.

Step 4: Rate Reproducibility

Assign a reproducibility rating, because it directly affects how engineering triages:

  • Always — reproduces 100% of the time with known steps
  • Intermittent — reproduces sometimes; note any pattern (specific browser, timing, data state)
  • Once / Unconfirmed — observed but not yet reproduced
  • Cannot reproduce — steps provided but issue does not recur

If reproduction steps are missing or incomplete, generate a numbered "steps to reproduce" attempt from the notes and label it as reconstructed, flagging any gaps.

Step 5: Form a Root-Cause Hypothesis

Offer 1–2 plausible cause categories to give engineering a starting direction — clearly labeled as a hypothesis, not a diagnosis:

  • Likely layer (frontend / backend / data / integration / config / third-party)
  • Reasoning in one sentence tied to the observed behavior
  • If the notes give no signal, state "Insufficient information for a hypothesis."

Step 6: Recommend the Escalation Path

Route the defect and set urgency:

  • Owning team: Best guess at responsible team based on product area (e.g., Payments, Content Platform, Assessment Engine, Infra)
  • Urgency: Immediate (page/on-call) / This sprint / Backlog — derived from severity + impact + reproducibility
  • Priority label: P0 / P1 / P2 / P3 mapped from severity and business context
  • Handoff readiness: "Ready for engineering" or "Blocked — needs [specific missing input]"

Output Format

  • Structure: A single structured triage card — labeled fields, not prose paragraphs
  • Length: 200–350 words
  • Format: Scannable field-value layout with a short "Reproduction Steps" numbered list and a one-line summary at top
  • Sections: One-line Summary → Severity → User Impact → Reproducibility → Reproduction Steps → Root-Cause Hypothesis → Escalation Path → Missing Info (only if applicable)
  • Tone: Neutral, factual, engineering-ready — no hedging, no emotional carryover from the original report

Quality Checklist

Before delivering output, verify:

  • [ ] Severity is one of exactly four levels (S1–S4) with a stated reason
  • [ ] Reproducibility is one of the four defined ratings — not left blank
  • [ ] Reproduction steps are present as a numbered list (reconstructed and labeled if the reporter didn't provide them)
  • [ ] Root-cause content is explicitly labeled as hypothesis, never stated as confirmed fact
  • [ ] Escalation path names an owning team, an urgency level, and a P0–P3 label
  • [ ] Any unknown field says "Unknown — needs confirmation" with the specific missing detail, rather than being fabricated

Notes

  • Severity measures how bad the defect is; priority measures how soon to act. Keep them distinct — an S2 with widespread impact can outrank an S1 affecting one internal user.
  • When multiple defect notes describe the same underlying issue, consolidate them into one card and note the report count as a frequency signal.
  • The single most common triage failure is missing reproduction steps — always attempt a reconstructed set so engineering isn't blocked on a round-trip.
  • Resist over-escalating. Reserve Immediate/P0 for genuine S1 conditions; inflating urgency erodes trust in the triage.

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