From Jira ticket to pull request: a five-step AI workflow for Sitecore

A content editor files a bug: on a handful of standalone page types, the product comparison and the watchlist among them, the Breadcrumb Title field cannot be maintained. In the original German: "Das Feld wird einfach nicht angezeigt." The field is simply not displayed. Priority Minor, two screenshots, no comments. It sat in the backlog for seven weeks, which tells you how it fared in sprint planning.

This post walks that ticket from Jira to a pull request, with an AI agent doing the work. In the first post I described how our setup grew out of daily work on a ten-year-old Sitecore solution, and that the workflow was built by working exactly one real ticket and extracting each step along the way. This is that ticket. It is also the story of how the workflow earned enough trust to run without me, because that was the goal from the start.

Five steps, five artifacts

The workflow consists of five steps, each one a skill: the small instruction files our agent, Claude Code, loads on demand. One command chains them, pausing at defined points for a human. Each step writes an artifact into a specs folder in the repository, right next to the code:

specs/<ticket>/
  summary.html               1  the ticket restated, plus open questions
  implementation-plan.html   2  approach, affected areas, deploy paths
  implementation-notes.html  3  running log: decisions, deviations, tradeoffs
  verification.html          4  independent acceptance check, PASS or FAIL
  pr-body.md                 5  the pull request description

The artifacts are not documentation for its own sake. They are the hand-off mechanism: no data is passed between the steps, each one reads what the previous ones wrote. I underestimated how much this one decision would carry. It makes the workflow resumable: when a run dies, or a gate stops it overnight, the next run checks which artifacts exist and continues from the first missing one. It makes the work auditable: weeks later, "why was it done this way" is answered by opening a file that was written at the time. And, as it turned out, it is what made the human gates removable at all. That part comes later.

The paper trail of one real ticket

The summary is where I expected the least and got the most. It restates the request, locates the field definition and traces it through the Glass Mapper model into the breadcrumb view. Ordinary code archaeology. What made me sit up was the wording: the root cause is recorded as a hypothesis, together with the exact check that would confirm it. Not "the templates are missing a base template" but "probably, and here is how to verify it". The summary also records what the agent could not see: the ticket's two screenshots were not retrievable through the API, so it flags them for a human to check instead of quietly guessing their content. An agent that guesses confidently is far more dangerous than one that writes down what it does not know.

The plan chose the smallest possible fix: add the missing base template to the affected page templates. A pure Sitecore item change, no C#, no frontend. Along the way it checked all the other page templates and found two more with the same gap, so the scope grew from three page types to five, confirmed with the reporter first.

My favorite part is a card titled "correction to the summary": a specialist sub-agent proved that the summary had pointed at the wrong item, the section item rather than the inheritable template, and recorded the proof. That card is when I understood what the artifacts were really for. Each step gets to challenge the previous one in writing, and the disagreement is preserved instead of papered over.

The implementation notes are a running log, not a report polished after the fact. Halfway through, the local Docker environment failed with a Windows networking fault; after a reboot, the run resumed at the step where it had stopped, because the artifacts said where that was. The notes also record the day's real lesson: the agent's first attempt to write the base templates used the wrong separator, a value that looks perfectly fine on a raw read and is silently broken for the template engine. That incident deserves a post of its own, and it is the next one.

Not grading its own homework

The verification step is the heart of the whole construction, and the reason everything else could be relaxed later. It runs as a fresh agent with a clean context, and it derives the acceptance criteria from the summary, the restated original request. Not from the implementation notes. The verification artifact states this explicitly: the implementer's notes were not present in its working copy and were not relied on. The agent that checks the work does not get to know what the agent that did the work considered done. This sounds paranoid until you let an agent verify its own work in the same session once: it will happily confirm that the code does what the code does. Independence is not a nice-to-have here. It is the entire value.

For this ticket the verifier derived three criteria. The field is editable on all five page types. A maintained value actually renders in the breadcrumb of the live page: it set a clearly marked test value, cleared the caches, reloaded the page and took a screenshot. And an empty field still falls back to the item name, so nothing regressed on the pages that leave it empty. Three out of three passed, the test value was reverted, and the artifact lists what it did not cover: the German-language rendering was verified as editable, but not separately screenshotted. A verification that admits its gaps is one I can calibrate against. One that claims completeness I would have to re-check entirely.

By the time the pull request opens, its description is almost a by-product: a distillation of the other four artifacts. The functional change is five one-line template additions, and the description says exactly that, pointing the reviewer at those five lines and treating everything else as context. That is the quiet payoff of the paper trail. The pull request does not need to be written, it needs to be condensed.

Earning the unattended mode

We did not start unattended, and I would not recommend starting there. The first version of the workflow paused wherever a step stopped being reversible: unanswered questions, plan approval, changes to the running Sitecore instance, the pull request going out. At first I clicked through every one of those gates, and that was not wasted time. It is how I learned what the agent gets right on this codebase, and what it reliably does not.

The goal, though, was always to remove myself, and what made that possible was not the agent getting smarter. It was the gates changing character: unattended, every gate becomes a documented decision instead of a pause. Open questions turn into stated assumptions that travel into the pull request description, and the verification verdict decides how the run ends. A clean PASS publishes the pull request, a PARTIAL stays a draft with the gaps flagged, a FAIL means no pull request at all.

Trust arrived in increments you can date. Unattended runs ended in drafts, always, until the first batch came back with verifications I could not fault; since then, a clean PASS publishes. Today the hard gate sits at the pull request, nothing merges on its own, and even that may move once the track record justifies it.

Not every ticket is a fit for this. The unattended workflow is at its best on small maintenance tickets with a symptom you can verify against the running system. What surprised me is how well it copes with vague ones: where I expected failed runs, the missing information came back as documented assumptions in the pull request, and I confirm or correct them in review instead of answering questions up front. And once single tickets run unattended, the next step suggests itself: handing the workflow a whole batch of them. On this project those run strictly one after another, because every ticket ends up deploying to the same shared local Sitecore instance. That is a story for later in the series.

Wrapping up

The pitch for AI coding agents is usually speed. After a month of putting real tickets through this workflow, I think that misses what actually changed. The artifacts and the independent verification did not make the agent faster. They made it inspectable, and inspectable is what let the gates come out. An agent that produces a diff gives you code to review and nothing else. An agent that leaves behind a summary, a plan, a log of its own deviations and a verification it was not allowed to influence gives you something much closer to a colleague's work.

The next post follows the workflow into the place where an agent can do the most silent damage on a Sitecore project, the content tree, and tells the story of the wrong separator properly.