The prompt
Score 10 of 10, Excellent
Use it when Your bug list has grown past what the team can fix, and you need an order based on how bad each bug is and how many customers it hits.
- {{bug_list}}
- {{severity_scale}}
- {{product}}
- {{capacity}}
- {{commitments}}
- {{triage_team}}
Full prompt and why it works
System prompt
You help product and engineering teams triage bugs. You rank by evidence about severity and reach, keep your reasoning visible, and never invent reports, counts or customers.
User message
<bugs> {{bug_list}} </bugs> <severity_scale> {{severity_scale}} </severity_scale> <context> Product: {{product}} Team capacity for bug fixes in the next cycle: {{capacity}} Customers or commitments that need special care (contracts, service levels, renewals): {{commitments}} </context> Triage the bugs above, for {{triage_team}} to agree an order at the next triage meeting, so that the team fixes what hurts customers most within the capacity we have. For each bug, judge: - Severity, using our scale above. If the scale says "none", use: Critical (data loss, a security problem, or a core task impossible for everyone), High (a core task impossible for some users, or possible only with a hard workaround), Medium (a workaround exists), Low (cosmetic). - Reach: how many customers or reports are affected, from the counts in the list. - Workaround: yes, partial or none. - Trend: whether reports are rising, where dates are given. Produce: 1. A ranked table with the columns Rank, Bug ID, Title, Severity, Reach, Workaround, Why this rank (under 15 words). 2. A cut line: the bugs that fit within the capacity above, using the effort estimates in the list, and the ones that fall below it. 3. Escalate now: bugs that touch security, data loss, payments or a listed commitment, whatever their rank. 4. Possible duplicates: bugs that look like the same problem, grouped, with a one-line reason. 5. Needs information: bugs that cannot be ranked yet, each with the one question to ask the reporter. <example> The form of one Why this rank cell: "High severity, 31 reports in two weeks, no workaround for admins." </example> A good triage lets anyone in the meeting see why one bug sits above another. Rank by severity first and reach second, and say where you departed from that order and why. Use only the reports, counts and estimates in the list; do not guess how many customers are affected or how long a fix will take. Do not close a bug, mark it won't fix or merge duplicates as a decision; propose it, because those calls belong to the team. If a bug has no effort estimate, keep it in the ranking and mark it "no estimate" beside the cut line rather than guessing one.
Variables
- {{bug_list}}
- The open bugs, one per entry, with ID, title, description, report count, affected customers, dates and effort estimate where you have them.
- {{severity_scale}}
- Your team's severity definitions, pasted. Write "none" to use a standard four-level scale.
- {{product}}
- Your product, in a few words.
- {{capacity}}
- How much fixing the team can do next cycle, for example "about 15 points" or "one engineer for two weeks".
- {{commitments}}
- Accounts or terms that need special care, for example "enterprise service level: critical bugs fixed in 5 days", or "none".
- {{triage_team}}
- Who decides the order, for example "the PM, the engineering lead and the support lead".
Why it works
- What good looks like. Severity comes first and reach second, and every departure from that order is explained, so the ranking can be argued with on its merits.
- What to avoid. Closing, won't-fix and duplicate calls come back as proposals for the team, never as decisions made by the model.
- If unsure. Bugs that cannot be ranked get one question for the reporter, and missing effort estimates are marked beside the cut line instead of guessed.