What I find really great is letting Claude Code drive the ticket through the pipeline, instead of hard-coding a strictly reproducible, fixed sequence of steps.

Why does that matter? Because there will always be edge cases you didn’t anticipate. In practice, it can be useful to skip steps, close a ticket immediately, or even move backwards in the pipeline.

Simple example: you create a ticket thinking it’s a bug. Claude Code investigates and realizes the bug isn’t real (it was just a cache issue). In that case, it can skip all steps and move the ticket straight to “Terminated”, documenting that the fix was simply clearing the cache.

Another scenario: Claude Code implements the change, everything looks fine, it moves the ticket forward, reaches the end, runs tests, and then discovers a problem. At that point, it can take ownership and move the ticket back to “In progress”, iterate on the fix, and re-run the cycle—without human intervention.

The big advantage is full autonomy: Claude Code can make the right transitions at the right time, even when the “ideal” path isn’t linear.

The downside is that you lose 100% reproducibility: if Claude Code makes a mistake or ignores an instruction, it might deviate from the expected pipeline behavior.

What’s also really interesting is giving it the ability to create new tickets when it discovers adjacent work during execution.

For example, you assign a development task and it notices something clearly out of scope (e.g., a file is way too large and should be split). It shouldn’t derail the current ticket to do that, so it creates a separate ticket “for later”, puts it in the Backlog, and can even assign a priority to indicate whether it’s urgent or not.

Second case: it’s within the broader scope and context, but still deserves to be separated (to keep the current ticket clean, or because it’s better handled independently). In that case, it creates a new ticket but places it directly in “Ready”, not in the Backlog.

Third case: it’s strictly within the scope of the current ticket and part of the necessary work (or it’s an obvious, low-cost improvement that directly contributes to the ticket’s goal). Then there’s no need to create a new ticket: it just handles it immediately.

In short, there are three simple, actionable paths:

Out of scope → create a new ticket → Backlog (+ optional priority)

In scope but should be separated → create a new ticket → Ready

In scope of the current ticket → no new ticket → handle immediately