Triage incoming bugs in Jira

New bug reports arrive half-complete and land on whoever is on triage duty. An Orkeste agent reads each new bug in Jira, comments with the likely component, a severity assessment and a suggested owner, asks for missing reproduction steps and posts the critical ones to your engineering channel.

The problem

Triage takes an hour a day from a senior engineer. Bugs wait without a severity, duplicates go unnoticed and the critical one is found in the afternoon.

How the workflow runs

Runs: Every hour, or when you start it.

  1. Find new bugs: The agent runs a JQL search for bugs created since its last run, up to ten per search.
  2. Read each bug: It reads the summary, the description and the reproduction steps.
  3. Assess: It names the likely component, the severity and a suggested owner from its briefing, and lists missing information.
  4. Look for duplicates: It searches Jira for similar open issues and mentions them.
  5. Comment and alert: It adds its assessment as a comment and posts critical bugs to the engineering channel in Slack.
  6. The lead decides: The engineering lead sets the priority, the assignee and the sprint in Jira.

The agent comments and alerts; priority, assignee and sprint stay with the engineering lead. Comments can also wait in Validations.

Who does what

What this workflow does not do

Works with your stack

Questions about this workflow

Can it assign the bug?

No. In Jira, agents search and read issues, create issues and add comments. The comment suggests an owner; the lead assigns.

Can it find duplicates?

It searches Jira for similar open issues and lists them in its comment, so the lead can link or close the duplicate.

Does it work with Linear?

Yes. In Linear, agents can also update an issue's status, so triage can move the issue to the right state.

Related workflows

Keep reading