Files, transitions, and searches bugs in the team's tracker - Jira, Linear, GitHub Issues, or Azure DevOps - through one tracker-agnostic workflow: authenticate, dedupe-search before creating, create with severity/priority classification, transition lifecycle states, and wire idempotent CI-driven filing from test failures. Jira Cloud REST API v3 is worked in full in the body (ADF descriptions, runtime transition lookup, JQL triage and duplicate queries, dry-run bulk transitions); Linear's GraphQL API (issueCreate/issueUpdate, workflowStates resolved by type, the 0-4 priority enum), GitHub Issues REST (open/closed + state_reason, label-based severity/priority), and Azure DevOps Work Item Tracking (JSON Patch, WIQL, process-template states) each have a deep reference. Use when programmatically managing the bug lifecycle on any of the four trackers: creating from CI failures, triaging queues, transitioning states, or dedupe-searching.
94
96%
Does it follow best practices?
Impact
94%
1.01xAverage score across 10 eval scenarios
Low
Low-risk findings worth noting
{
"context": "Fifteen matches, nine of which should be finished. Five must be excluded and each is excluded for a different reason: ENG-5012 and ENG-5015 were fixed but never confirmed by anyone, ENG-5020 belongs to the following release and was caught by the query's `fixVersion >=` clause, ENG-5023 is a deferred item caught by the label clause and needs a product decision rather than a sweep, and ENG-5028 is already finished. OPS-2210 is legitimate but sits on a board whose workflow does not have the transition the runbook hard-codes, and the runbook's 'if a key 400s, skip it and carry on' turns that into a silent miss. Predicted baseline failure: the agent reviews the ticket list, correctly drops the two obviously wrong rows (the following release and the already-closed one), and hands back a cleaned-up script that applies the transitions in one pass - because that is what was asked for and it looks efficient. The two fixed-but-unconfirmed tickets are the most commonly swept in, since the release notes say the fix shipped. The hard-coded transition id is almost never challenged: it is presented as verified in March and reads as a settled configuration value rather than as a per-board, per-workflow identifier that has to be looked up at run time.",
"type": "weighted_checklist",
"checklist": [
{
"name": "All three deliverables produced",
"description": "sweep-plan.md, sweep-scope.csv (key,decision,reason) and runbook-changes.md all exist, and every one of the 15 matched keys appears exactly once in the CSV. Missing a file, or a CSV that omits keys, scores at most half.",
"max_score": 6
},
{
"name": "Exclusions complete and individually reasoned",
"description": "ENG-5012 and ENG-5015 (fixed, never confirmed by anyone), ENG-5020 (following release, caught by the `fixVersion >=` clause), ENG-5023 (deferred, caught by the label clause, needs a product decision) and ENG-5028 (already finished) are all excluded, each with its own reason. Sweeping in ENG-5012 or ENG-5015 scores zero regardless of the rest; missing any one of the other three exclusions scores at most half.",
"max_score": 30
},
{
"name": "Run is listed and counted before it is applied",
"description": "The plan states the exact keys and count the run would touch, and names the check the lead performs - the listed set and count must match the intended set before the run is allowed to proceed, and if they do not, the query gets fixed and re-listed. MUST NOT hand back a runbook or command that applies the transitions in a single unreviewed pass: a mis-scoped filter here is what put four tickets from the next release into a finished state, and a finish is not cleanly reversible. Any deliverable whose operative instruction is 'run this now' scores zero here.",
"max_score": 22
},
{
"name": "Hard-coded transition identifier rejected",
"description": "The literal transition id 31 is called out as unsafe to carry between boards and across workflow edits, and is replaced by looking up the available transitions for each ticket at run time and matching the one that finishes it. Keeping id 31 while noting 'confirm it still works' scores at most half; leaving it unchallenged scores zero.",
"max_score": 18
},
{
"name": "Second project handled as a different workflow",
"description": "OPS-2210 is identified as sitting on a board whose workflow may not offer the same transition, so the run must resolve the finishing transition for that board rather than assume the ENG one. Excluding OPS-2210 entirely with the reason stated is acceptable; ignoring the project difference scores zero.",
"max_score": 14
},
{
"name": "Silent skip on failure rejected",
"description": "The runbook's 'if a key 400s, skip it and carry on' is called out: a ticket that could not be transitioned must surface as a failure, otherwise a whole board can be silently missed while the run reports success. Leaving that line in place scores zero.",
"max_score": 12
},
{
"name": "Finish set enumerated",
"description": "The nine keys to be finished are listed explicitly (ENG-5001 through ENG-5009), not described as 'the rest'. A plan that names only the exclusions scores at most half.",
"max_score": 8
}
]
}