A Jira ticket resolved by an agent, with a human in the loop where it matters
#Most of the work on a Jira ticket needs no person: reading it and its attachments, finding where in the code it lands, writing the change and reviewing it. This reference project carries one skill that does all of it, and a person decides only where a mistake would cost something: the plan before any file changes, anything the reviewer proposes beyond that plan, and the commit and push. Once the change is on the remote, the skill comments on the ticket, moves it to In Review and hands it back to whoever raised it.
The skill is written instructions, not program code. The panels below show its files and rules as pseudocode: the concepts, not the source. Two details make the shape legible: eleven phases sit behind a short router that points to one file per phase, and the run produces two things, a change in the working tree and a written result on the ticket.
analyze-and-resolve-jira-issue/├── SKILL.md // the router — one row per phase└── references/ // one file per phase, loaded aloneConfidence decides the route
The analysis rates its own confidence before anything else happens, and a low rating routes to questions instead of to a plan. Without that branch the skill writes a confident plan on top of a guess, which is the most expensive thing it could produce.
confidence = high | medium | lowlow means ask; never plan from itstill low after two rounds of questions: stophigh still means no automatic implementationThe plan is confirmed before any edit
No file changes until a human has read the proposed resolution and agreed to it. Confidence is not consent, and a skill that skips this step is only fast until the first time it is wrong.
propose the plan, then wait for approvalapproved: implement, scoped to this repositoryThe reviewer is not the author
The implementation is checked by a separate agent that starts with an empty context and does not edit. A reviewer sharing the author context re-reads the reasoning that produced the code and agrees with it.
review = fresh context, read onlyfindings inside the plan: the main thread fixes themproposals beyond the plan: a person decidesat most two roundsA person at the gates that matter
Reading and analysing run on their own, and the skill asks questions only when it is unsure. A person decides on the plan, on anything the reviewer proposes beyond it, on whether to check the change by hand, and on the commit and push. Nothing leaves the machine without that last answer.
gates: the plan · proposals beyond it · a manual check · commit and pushno branches, no history rewriting, no skipped hooksthe status moves only once the change is on the remoteThe write-back is for the reporter
The comment posted to the ticket is written for whoever raised it, and a checklist strips engineering residue before it is sent. A comment full of file paths and phase numbers reports the process instead of the outcome.
comment = a business summary, then the detailsstrip: file paths, commands, commit hashes, phase numbers, subagents, iteration countsoptional: what to test around the changeOne rule keeps the tracker honest. A status may only move after the change is on the remote, so the ticket can never assert something the world has not seen. If the push is declined the run ends cleanly and the ticket is left exactly as it was — no comment, no transition, no reassignment.
- 11phases, one reference file each
- 3decisions a person makes on every run: the plan, a manual check, the push