Skip to content
Tulina
Book a demo
← Processes

Triage and route bug reports

An incoming report is read, matched against open issues to catch duplicates, and filed to the right team's board with severity attached.

Book a demo
Linear→Slack
Starts
New bug report
Steps
5
Checks and gates
0
A person decides
Never, runs alone

Trigger · Event

New bug report

Each incoming report starts the run as it lands, so triage happens in minutes rather than at the next sweep.

Linear

Claude runs the rest autonomously

  1. 1

    AI labels what the report leaves out.

    Symptom, repro steps, environment, frequency and impact are pulled out, and whatever the report did not include is labelled as missing.

  2. 2

    AI titles the issue on the symptom.

    The issue is titled on what was observed, and the reporter's guessed cause stays in the body, attributed to them.

  3. 3

    AI catches duplicates and regressions.

    Linear

    Linear

    A report matching an open or recently closed issue is added to it instead of filed again, and a match on a closed one counts as a regression.

  4. 4

    AI sets severity from stated impact.

    Each issue gets a severity band from the impact described rather than the tone, raised when several accounts report it or it is a regression.

  5. 5

    AI files it on the owning team's board.

    Linear

    Linear

    The issue lands on the board that owns the area, with any doubt about ownership flagged on it instead of left in a triage queue.

    Slack

    Slack

Triage is a job that is easy to do badly and invisible when done well. A report arrives, somebody skims it, files it wherever seems reasonable, and assigns a severity based mostly on how the reporter sounded. Two weeks later the same bug has three open issues on two boards, one of which is a regression nobody spotted because it matched a closed ticket that nobody searched.

Almost none of that requires product judgement. Extracting a symptom, searching for an existing match, deciding a band from stated impact, and mapping a surface to its owning team are all mechanical, and doing them consistently at 200 reports a week is precisely where humans stop being consistent. That consistency is the case for running bug triage with an AI agent: every report gets the same five checks as it arrives.

What you get

Every report lands on the owning team's board within minutes, deduplicated against what is already open, with a severity that reflects what the reporter actually described.

What AI bug triage pulls out of a report

Each report is read as it arrives, and five things are extracted, in the reporter's own words where possible: the symptom, the reproduction steps, the environment (browser, device, version, account), how often it happens, and the impact, meaning whether the reporter is blocked or working around it.

Whatever the report leaves out is labelled as missing. A report with no reproduction steps is still worth filing, but it has to say so visibly, because "cannot reproduce" and "was never told how" lead to opposite decisions when someone later considers closing the issue.

The symptom goes in the title, never the reporter's diagnosis. People supply causes with their reports and the causes are often wrong: "the cache is broken so my dashboard is empty" is one observation and one guess. A title stating the guess sends the issue straight to whichever team owns the thing they guessed at, where it is correctly closed as not-a-bug while the real problem stays open. The guess goes in the body with the reporter's name attached, and the issue lands wherever the symptom points.

Catching duplicate bug reports and regressions

The tracker, Linear here, is searched on the symptom, matching by substance rather than by wording: open issues first, then recently closed ones. A report that already exists becomes a comment on the existing issue, carrying the new report's specifics and its reporter, and the response says it was linked.

Searching closed issues is the step that pays for itself. A report matching something closed last week is a regression: the fix did not hold, or it held and something else broke it. Triaged as a new bug, it starts at the back of the queue with no history, and the person who fixed it the first time never finds out. One extra query changes that outcome, and the regression is treated as more urgent than a new bug.

Setting severity from impact and filing on the right board

Severity comes from what was described, never from how the reporter sounded. An angry report about a cosmetic misalignment is not urgent, and a politely worded note about corrupted exports is. The bands follow the impact:

  • blocked with no workaround, or data lost or shown wrongly, is the top band;
  • a workaround that has to be performed repeatedly is the next;
  • cosmetic, or affecting one unusual configuration, is the lowest.

Two facts raise the band: how many accounts have reported the same thing, and whether it is a regression.

The issue is then filed on the board of the team that owns the affected surface. Where ownership is ambiguous, it goes to the most likely board with the doubt flagged on the issue itself. An issue left unassigned in a triage queue pending a routing decision is the most common way a real bug goes stale.

Only the top band is also posted to Slack. Routing every routine report into chat teaches the team that the channel is background noise, and the alert that genuinely needed a response in ten minutes gets the same treatment as the misaligned button from Tuesday.

The prompt

The real prompt behind the steps above, detailed enough that an agent with the same tools can run it as written. The Run buttons copy the full version, which also carries the steps for connecting those tools.

# Triage and route bug reports

You have access to an issue tracker and a messaging tool. Run this on
**[each incoming bug report]**.


## 1. Label what the report leaves out

Extract, in the reporter's own words where possible:

- The symptom. What happened, not what they think caused it.
- Reproduction steps, if given.
- Environment: browser, device, version, account.
- Frequency: once, intermittent, or every time.
- Impact: blocked entirely, or working around it.

Where reproduction steps or environment are missing, say so
explicitly. A report with no repro is still worth filing, but it must
be visibly labelled, because the difference between "cannot reproduce"
and "was never told how" is the difference between closing an issue
correctly and closing it wrongly.

## 2. Title the issue on the symptom, not the diagnosis

Reporters routinely supply a cause along with the effect, and the
cause is frequently wrong. "The cache is broken so my dashboard is
empty" is one observation and one guess.

File the observation. Keep the guess in the body, attributed to the
reporter. A title describing a diagnosis sends the issue to the wrong
team and gets closed as not-a-bug while the actual problem stays open.

## 3. Catch duplicates and regressions

Search the tracker on the symptom, matching by substance rather than
by wording. Search open issues first, then recently closed ones: a
report about something closed last week is a regression, which is more
urgent than a new bug, not less.

When it already exists, comment on it with the new report's specifics
and reporter rather than filing a duplicate, and say in the response
that it was linked to an existing issue.

## 4. Set severity from stated impact, not tone

Severity comes from what was described, never from the reporter's
tone. An angry report about a cosmetic misalignment is not urgent, and
a politely worded note about corrupted exports is.

- Blocked with no workaround, or data being lost or shown wrongly, is
  the top band.
- A workaround exists but is performed repeatedly is the next.
- Cosmetic, or affecting one unusual configuration, is the lowest.

Two multipliers: how many accounts have reported it, and whether it is
a regression. Both should raise the band, and both are facts rather
than judgements.

## 5. File it on the owning team's board

Map the affected surface to the board that owns it. Where ownership is
ambiguous, file it on the most likely board and flag the ambiguity in
the issue rather than leaving it in a triage queue. An issue sitting
unassigned pending a routing decision is the most common way a real
bug goes stale.

Post to the channel only for the top severity band. Routine reports
going into a channel train everyone to ignore that channel, which
means the one that mattered is ignored too.

## Output

Report: reports triaged, matched to existing issues, regressions
identified, new issues created by board and severity, reports missing
repro steps, and the ones where ownership was ambiguous.

Why run it with Tulina

A prompt helps one person. A process moves a team.

Pasted into a chat, the prompt above works once, for whoever pasted it. In Tulina, "Triage and route bug reports" becomes a process the team shares, that keeps its history, runs on its own, and stays inside the same security perimeter as the tools it calls.

  • The whole team works on the same one

    PersonalTeamOrganisation

    A process lives where it belongs: yours, your team's or the whole organisation's. Whoever runs it can improve it, and everyone starts from the best version instead of explaining the job again.

  • Every edit is a version

    v1v2v3

    Each change is a new version with the previous one kept, so a bad edit is undone by restoring an earlier one. Every run records the version it followed, and what a run teaches goes back into the process.

  • It runs without you

    schedulewebhookon demand

    A hosted agent runs the process on Tulina's own infrastructure, on a schedule or when an event arrives, and keeps going when you close the chat. Nothing to host. Every run is tracked to its outcome.

  • Inside the same security perimeter

    vaultrolesrun log

    Credentials stay in the vault, never in the prompt. Roles decide who may run what, every call is logged, and a step a person has to approve waits for that person.

Questions about AI bug triage

Yes. An agent with access to the issue tracker can read each report as it arrives, pull out the symptom, repro steps, environment, frequency and impact, check for an existing issue, set a severity band and file it on the board of the team that owns the area. Where ownership is unclear, it files on the most likely board and flags the doubt on the issue instead of leaving it in a triage queue.

From what was described, not from tone. A furious report about a misaligned button stays low, and a calm note about exports containing wrong figures goes to the top band. Corroboration count and whether it is a regression raise the band, since both are facts rather than impressions.

Yes, by searching the tracker on the symptom, matched by substance rather than wording, across open issues and recently closed ones. A match on an open issue becomes a comment carrying the new report's specifics. A match on something closed recently is a regression, which is treated as more urgent than a new bug.

It still files it, but visibly labelled as lacking them. That matters later, because "cannot reproduce" and "was never told how to reproduce" lead to opposite decisions about closing the issue.

Also on Linear

Other processes that run mainly on Linear. The tools they share with this one are lit.

See Tulina in a 30-minute demo.

Book a demo