---
name: bug-triage-crew
description: >-
  Triage a bug report end to end the way a QA crew does: classify severity
  (P0-P4) with a justification, categorize it, trace the likely root cause down
  the UI -> API -> Service -> DB stack, flag possible duplicates, and recommend
  the tests that verify the fix and stop it coming back. Works from a Jira key or
  a pasted report, and writes a CLI table plus a shareable HTML triage report.
  Use when a tester or lead says "triage this bug", "what severity is this",
  "why is this happening and how do we test the fix", "triage the bug backlog",
  or "is this a duplicate". Always ends at a human review gate before anything is
  assigned or closed.
license: MIT
metadata:
  author: TheTestingAcademy
  stlc-phase: Defect Management
  version: 1.0.0
---

# Bug Triage Crew

Three specialists in one skill: a triage analyst, a root-cause investigator, and a test strategist, run in that order so each builds on the last. It classifies and explains a bug; it must not assign it, change its status, or close it as a duplicate on its own.

## When to use
- A bug lands and needs a severity, a category, and a "so what" before sprint planning.
- The backlog has a pile of untriaged bugs and you want them sorted P0-first with reasons.
- A lead asks "is this really critical?" and wants the call justified, not just asserted.
- You suspect a duplicate and want the likely matches surfaced before you close anything.

## Workflow

1. **Gather the bug (never invent it).** From a Jira key: `python scripts/fetch_jira.py VWO-48 > bug.json`. Otherwise ask the reporter to paste the title, steps, and what they saw. If the report is thin, that thinness is a finding: list what is missing (repro, environment, expected vs actual) rather than filling it in.

2. **Triage (the analyst).** Read `references/severity-rubric.md` and classify:
   - **Severity P0-P4**, with a written justification against the rubric. Never inflate. If you bump a P2 to P1, say why the workaround does not count, or leave it a P2.
   - **Category**: UI, Functional, Performance, Security, Data.
   - **Affected component/module** and a one-line **business impact**.
   - A suggested **sprint priority** (advisory: the lead owns the real call).

3. **Root cause (the investigator).** Trace the bug down `UI -> API -> Service -> DB -> Infra -> Third-party` and name the single most likely layer, the probable cause, the related components, concrete investigation steps, and which **logs or dashboards to check first**. State confidence; if it is low, say what evidence would raise it rather than guessing.

4. **Check for duplicates.** Compare against the open/recent bugs you were given (or ask for that list). Surface likely matches with a one-line reason and a match strength. These are leads for a human, never an auto-close.

5. **Test strategy (the strategist).** Recommend a **verification** test that proves the fix, **3-5 regression** cases so it cannot silently return, **edge cases** worth adding, and an **automation** approach (Playwright TypeScript when it applies). Tie each back to the bug and its root cause.

6. **Emit + HUMAN REVIEW GATE (mandatory).** Write the decision to `triage.json` and render it:
   `python scripts/render.py triage.json --html triage.html`
   Present it as a DRAFT. State the confidence on severity and layer, what you assumed, and that severity/priority are advisory and duplicates are unconfirmed. Ask the tester or lead to confirm before anything is assigned, reprioritized, or closed. Do not transition the ticket, assign an owner, or close a duplicate yourself.

## triage.json shape

```json
{
  "bug": { "id": "VWO-48", "title": "...", "reporter": "...", "url": "..." },
  "triage": {
    "severity": "P1",
    "severity_reason": "why this and not one higher or lower",
    "category": "Functional",
    "component": "checkout / coupon reducer",
    "business_impact": "...",
    "sprint_priority": "This sprint",
    "confidence": "high"
  },
  "root_cause": {
    "likely_cause": "...",
    "layer": "Service",
    "related_components": ["..."],
    "investigation": ["step", "step"],
    "check_first": ["log or dashboard"]
  },
  "tests": {
    "verification": "...",
    "regression": ["...", "..."],
    "edge_cases": ["..."],
    "automation": "Playwright TS: ..."
  },
  "duplicates": [ { "id": "VWO-31", "why": "...", "similarity": "high" } ]
}
```

`render.py` accepts one object or a list (batch triage). It prints a P0-first
CLI table and writes a self-contained HTML report grouped by severity.

## Guardrails
- Never fabricate a bug, a repro step, an environment, or a log line. A missing detail is a finding, not a blank to fill.
- Never inflate severity. Every classification is justified against the rubric, and severity is technical impact, not urgency.
- Duplicates are leads, not verdicts. Do not close, merge, or link a ticket as duplicate without a human confirming.
- Do not assign, reprioritize, transition, or close the ticket. The skill decides and explains; a human acts.
- Root cause is a hypothesis with a confidence level and the logs to confirm it, never a stated fact.
- Retries and longer timeouts are not fixes and are not test recommendations. Recommend tests that would have caught the bug.
- Stay in Defect Management. Writing the fix, and the flakiness question, belong to other skills.