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
Both deliverables produced
100%
100%
Reports closed without the facts needed to reproduce are pulled back
100%
100%
Sound outcomes defended
100%
100%
Recoverable information sourced from the pipeline, not the reporter
93%
100%
Critical open item not closed out
100%
100%
Requests go on the existing tickets
100%
100%
Each returned ticket has a named recipient and a resting state
100%
100%
Both deliverables produced
100%
100%
WEB-512 corrected on both axes with separate reasoning
100%
100%
Deliberate divergence preserved
100%
100%
Missing damage ratings assessed, not copied
100%
100%
WEB-531 scheduling corrected without touching its damage rating
100%
100%
Classification moved out of the title
83%
100%
Genuinely cosmetic tickets untouched
100%
100%
Every proposed change carries a checkable basis
100%
100%
Both deliverables produced
100%
100%
Unconfirmed closures identified by the state sequence
100%
100%
Nominal confirmations rejected
100%
100%
Untriaged close identified
100%
100%
Sound closures left alone
100%
100%
Plan is reviewable before it is applied
100%
100%
Each moved ticket has a next actor and a target state
100%
100%
Both deliverables produced
100%
100%
Unowned urgent items named, including the bot-assigned one
100%
100%
Low-urgency breaches reported too
100%
100%
Severity not used as a scheduling lever
100%
100%
Aged items get a decision, not a cleanup close
100%
100%
Items inside the window or legitimately parked left alone
100%
56%
Undecidable item handled as undecidable
100%
58%
Each action has a named owner
50%
62%
Both deliverables produced
100%
100%
Written-down lifecycle identifiers replaced by run-time lookups
87%
100%
Linear rename diagnosed as a lookup-by-name problem
100%
100%
The two boards on different templates separated
100%
100%
The silent overwrite explained
81%
100%
The reason-less close called out
92%
100%
Urgency value corrected
100%
100%
Remaining request-shape errors resolved
100%
100%
Both deliverables produced
100%
100%
Unavailable lookup must not fall through to a create
100%
100%
The 5 August behaviour explained from the code
100%
100%
Different failures kept out of the collapse
88%
100%
Surviving ticket chosen for what it carries
71%
71%
Recurrence lands on the existing ticket
100%
100%
Credential handled as a leak, not a style problem
100%
100%
Matching is signature-based, not title-based
80%
60%
All three deliverables produced
100%
100%
Exclusions complete and individually reasoned
100%
100%
Run is listed and counted before it is applied
100%
100%
Hard-coded transition identifier rejected
50%
100%
Second project handled as a different workflow
100%
100%
Silent skip on failure rejected
100%
100%
Finish set enumerated
100%
100%
Both deliverables produced
100%
100%
Live shipped change on APP-3011 addressed, and the ticket not closed
100%
100%
Repeated-recurrence ticket escalated on the pattern
100%
100%
Contradicted close reopened rather than re-filed
100%
100%
Re-filed recurrence collapsed into the original
100%
100%
Swept ticket returned to the fix path, not the incoming queue
100%
100%
Weekly figure corrected
100%
100%
Untouched tickets stated
90%
100%
Both deliverables produced
100%
100%
Cap-driven undercount identified with a completeness check, not a bigger cap
93%
90%
Zero traced to a failed query, not to an empty board
16%
0%
Failure and emptiness must not share a return value
93%
100%
Per-item field fetch inside the loop rejected
37%
100%
Interpolation named as an injection hazard as well as a bug
8%
58%
Sign-off verdict stated plainly
100%
100%
Findings ordered by impact
100%
100%
Both deliverables produced
100%
100%
Survivor is the ticket carrying the reproduction
100%
100%
Information moved before anything is stopped
100%
100%
Stopped tickets recorded with an explicit reason and link
100%
100%
Near-misses refused
100%
100%
Stale link chain repaired
100%
75%
Actions are per-ticket and executable
100%
87%
Table of Contents