copy paste

skills/debugging/bug-triage.md

@@ -0,0 +1,46 @@
+# Bug Triage
+
+## Purpose
+
+Frame a defect clearly before or during debugging so the team understands impact, reproduction, suspected scope, and next actions.
+
+## When to use
+
+- A bug report arrives with incomplete detail
+- A failing test or regression needs initial framing
+- Multiple issues compete for attention and severity matters
+- You need a reliable reproduction path before deeper debugging
+
+## Inputs to gather
+
+- Reported symptoms, expected behavior, and actual behavior
+- Reproduction steps, environment, and frequency
+- User impact, severity, and likely affected surfaces
+- Recent changes, logs, or tests that may be related
+
+## How to work
+
+- Turn vague symptoms into a concrete problem statement.
+- Reproduce the issue when possible and tighten the reproduction steps.
+- Separate confirmed facts from assumptions.
+- Estimate impact and likely blast radius before diving into fixes.
+- Identify the next best debugging step if root cause is not yet known.
+
+## Output expectations
+
+- Clear bug statement and reproduction status
+- Impact and severity assessment
+- Suspected scope or likely component area
+- Recommended next debugging or fix step
+
+## Quality checklist
+
+- The issue is described in observable terms rather than guesses.
+- Reproduction details are specific enough to be reused.
+- Impact is clear enough to prioritize intelligently.
+- Unknowns are named instead of hidden.
+
+## Handoff notes
+
+- Record environment details and whether the issue is deterministic, intermittent, or unconfirmed.
+- Pair with debugging workflow once the problem is framed well enough to investigate deeply.