CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/bug-tracker-workflow

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

1.01x
Quality

96%

Does it follow best practices?

Impact

94%

1.01x

Average score across 10 eval scenarios

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Evaluation results

100%

1%

"Cannot reproduce" is our second most common outcome

Criteria
Baseline
With context

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%

100%

2%

A token-leak ticket has been sitting in the cosmetic pile for five weeks

Criteria
Baseline
With context

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%

100%

Bugs are coming back after we close them

Criteria
Baseline
With context

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%

86%

-10%

Nothing in the incoming queue has an owner and the oldest is nine days old

Criteria
Baseline
With context

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%

100%

7%

One automation, five boards, and a config file full of pasted-in values

Criteria
Baseline
With context

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%

93%

Our CI job opened 16 tickets for one flaky test

Criteria
Baseline
With context

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%

100%

9%

Someone wants to clear 15 tickets in one pass before the retro

Criteria
Baseline
With context

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%

100%

1%

The same defects keep coming back and our weekly numbers say we're improving

Criteria
Baseline
With context

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%

73%

9%

The weekly defect report says the board is clean and the board is not

Criteria
Baseline
With context

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%

96%

-4%

Three tickets for one checkout failure, and only one of them is usable

Criteria
Baseline
With context

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%

Evaluated
Agent
Claude Code
Model
Claude Sonnet 4.6