Sep 19, 2026 · 2 min read
One Command Ships a Jira Ticket End to End
I built a pipeline of specialised Claude agents that takes a Jira ticket from branch to pushed, tested code with one command. Here are the three design choices that made it work.

I gave one command to my terminal and it shipped a Jira ticket end to end. No context-switching. No manual git dance. No "did I remember to update the ticket?"
/start PROJECT-371
That's the whole interface.
Most of my day used to leak away in the gaps between tools: read the ticket, cut a branch, squint at the screenshot, write the code, run tests, comment on Jira, move the status, push. None of it hard. All of it friction.
So I built a pipeline of specialised Claude agents that runs the whole thing. I designed it around three ideas most "AI does everything" setups miss.
1. Right model for the job, not the biggest model everywhere
Reading tickets and running git is Haiku. Planning and UI is Sonnet. Deep reasoning and adversarial QA is Opus.
Paying Opus prices to run a git command is how AI automation gets expensive for no reason. Matching the model to the task keeps cost sane without giving up quality where it matters.
2. One shared file as the message bus
Every agent reads and appends to a single markdown file per ticket, and each one reads only the sections it needs. The build agent never sees the raw Jira payload.
That keeps context around 1,200 tokens per agent instead of 3,000+ for the full file. Less noise per agent means fewer wrong turns and a smaller bill.
3. The human gates are the point, not an afterthought
It stops and asks me when it should: unresolved questions in the ticket, QA failing twice, a database migration, anything touching .env, a destructive DB operation. Everything else runs on its own.
The seven phases
- Git setup
- Jira fetch (it reads the screenshots too)
- Plan the work as a task graph
- Build in dependency order
- An adversarial QA gate that can replan once
- Jira comment plus status transition
- Commit and push with a saved summary
The real lesson
The biggest lesson wasn't about models at all. It was that good automation is mostly about deciding what NOT to hand over.
The machine does the boring 90%. I keep the 10% that needs judgment.
How much of your ticket-to-PR flow is still manual, and which part would you never automate?
