Assign Bug Severity and Priority with AI
Reads a bug description and assigns SEVERITY (impact on system, 1-4) and PRIORITY (urgency to fix, 1-4) on independent scales, each with a written justification, plus a recommended SLA target. Refuses to collapse the two dimensions into one score.
When to use it
- You inherited a bug backlog where severity and priority are confused or missing.
- You're standardizing triage across a team where individual judgment varies.
- Stakeholders push for 'P1' on everything and you need a defensible rubric.
- You're triaging at velocity (50+ bugs/week) and need consistency.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a triage lead. You enforce the rubric — severity is impact-on-system, priority is urgency-to-fix, and they are independent. You give bullet-point justifications, not paragraphs, because triage volume demands concision.
</role>
<context>
Severity rubric:
- **S1 Critical** — Production down, data loss, security breach, regulatory violation
- **S2 Major** — Core feature broken for many users or workflow blocked
- **S3 Minor** — Degraded UX or workaround exists
- **S4 Trivial** — Cosmetic, typo, edge case
Priority rubric:
- **P1** — Fix in next hotfix / patch
- **P2** — Fix in next planned release
- **P3** — Fix when convenient, within 1-2 quarters
- **P4** — Backlog, may not fix
Severity and Priority are INDEPENDENT. A Critical bug in a feature 5 customers use can be P3. A Minor bug on the homepage can be P1.
</context>
<task>
For the bug description below:
1. Assign **severity** (S1-S4) with 1-2 bullet justification citing IMPACT signals.
2. Assign **priority** (P1-P4) with 1-2 bullet justification citing URGENCY signals (customer reach, business stakes, blast radius).
3. Recommend an **SLA target** (e.g., "Resolve within 24h", "Resolve before next release").
4. Note any **ambiguity** that would change the decision if resolved.
</task>
<input>
Bug description: {description}
Reach (estimated users affected, if known): {reach}
Workaround (if any): {workaround}
Business context (e.g., enterprise demo tomorrow): {context}
</input>
<constraints>
- Severity is impact-on-system, not "how angry the reporter is".
- Priority is urgency, informed by reach, business context, and presence/absence of workaround.
- DO NOT combine them into a single score.
- SLA target must be SPECIFIC ("Resolve within 24h" not "Soon").
- If business context suggests inflating priority above severity warrants, name that explicitly.
</constraints>
<output_format>
Four sections:
1. **Severity** — S1-S4 with bullet justification
2. **Priority** — P1-P4 with bullet justification
3. **SLA target** — one line
4. **Ambiguity** — bullets or "None observed"
</output_format>
Before writing, ask yourself: if reach doubled, would priority change? If yes, you have your priority signal.Example
Common pitfalls
- Model assigns the same number to both fields (S1/P1 default). Re-prompt with explicit independent-rubric reminder.
- Severity gets inflated when reporter is angry or VIP; force focus on system impact.
- Workaround is ignored when assessing priority — its presence should usually lower priority, not always but often.
- SLA recommendation comes out as 'Fix ASAP' — vague. Require a concrete time or release-based target.
Tips
- Provide REACH whenever you can — analytics counts, customer segments. The model's priority judgments improve dramatically with real reach data.
- Re-triage stale bugs quarterly; reach and business context shift.
- Use this in tandem with `write-bug-report` to ensure the bug ticket has the data fields the triage rubric needs.
- Train the team to write reports with REACH and CONTEXT fields up front — saves time at triage.
FAQ
There are 16 combinations and they're all valid. A common (and correct) one is S1 + P3 — a critical-severity bug in a deprecated module nobody uses. Trust the rubric output instead of trying to predict 'reasonable' combinations.
Related prompts
Write a Detailed Bug Report
Takes a free-form issue description (Slack message, email, support ticket) and returns a structured bug report following the AQA Pro Bug Report Template — clear `[Component] Verb-noun` title, environment, separate severity and priority, numbered atomic repro steps, expected vs actual, and suggested investigation areas.
Open →Root Cause Analysis (5 Whys + Fishbone)
Given a defect description, returns a literal 5 Whys chain, a fishbone diagram (text representation) categorizing contributing factors into People / Process / Technology / Environment, and a list of preventive measures with named owners — never generic recommendations.
Open →Duplicate Bug Detector
Given a new bug description and N existing bug summaries, returns a ranked list of duplicate candidates with similarity scores (0-100) based on ROOT-CAUSE likelihood rather than surface text — with one-line evidence per candidate.
Open →Risk-Based Testing Prioritization
Reads a feature list and outputs a prioritization matrix with four weighted dimensions (business impact, technical complexity, usage frequency, defect history) scored 1-5, total weighted score, recommended test execution order, and tie-break rule.
Open →