I had hotfix-messaging-visibility open, a customer was waiting on a text-delivery fix, and git stopped me on .claude/skills/ticket/SKILL.md.

Not on a source file. Not on a database migration. On the prompt file that tells Claude how to run a ticket session.

My first reaction was mild irritation. Merge conflicts on prose files feel bureaucratic, not dangerous. This is just instructions, I figured. Read the diff, pick the version that makes sense, move on. I was treating a policy file as soft configuration, and it had just stopped a customer fix cold.

what the /ticket skill actually does

The /ticket skill at .claude/skills/ticket/SKILL.md was how I opened work sessions on production-app tickets. I typed /ticket 1234, and the agent session used the skill as its workflow instructions: how to resolve the ticket, choose an appropriate branch type, claim the repository lock, apply ticket-state transitions, record intent, and reserve a clone for the work.

That list matters because the skill shaped repeatable behavior across many sessions. It was not just reference prose; it encoded the branching and ticket-state policy the agent was expected to follow. If its logic for a ticket class was wrong, later sessions using that version could inherit the same wrong workflow.

I had thought of it as a prompt I could refine freely. By April 3rd, three tickets in one day taught me otherwise.

what changed that day

The first ticket was the text-delivery investigation. Customers were reporting unreceived texts. The session produced a new diagnostic page in the admin panel, and a set of JIRA transitions through the hotfix flow. Somewhere in that session I updated the skill to handle customer-type ticket priority correctly. The existing logic was ambiguous about how to sequence a customer-type issue through JIRA versus a standard staging ticket.

The second ticket came next: tournament org structure. The session produced a second diagnostic page in the admin panel. To work that ticket cleanly, I needed the skill to be smarter about role disambiguation, specifically how it handles tickets that sit at the intersection of multiple JIRA components. I edited the skill again.

The third ticket was a docs-viewer root-path fix. Smaller in scope but it exposed something in the branch-creation step. The skill had been cutting branches immediately at session open. The fix for a particular edge case was to defer branch creation until the first edit was actually imminent, after a fetch and sync step confirmed the clone was at the right base commit.

Three edits, three tickets, one day. Each edit felt like a local patch to address the ticket at hand. And then I tried to merge hotfix-messaging-visibility back, and git showed me that the skill file had diverged in two directions at once.

the conflict is not the bug

My first reading of the conflict was: this is a coordination problem. I touched the same file on two branches, now I have to reconcile them. Standard merge hygiene.

That reading was incomplete. The real problem was that I had been editing a file that shaped automated workflow behavior wherever that version was used, without considering what branch-specific skill edits meant once those branches interacted.

When a hotfix branch changes the skill’s JIRA transition rules and a feature branch changes its branch-deferred-creation logic at the same time, the conflict is not a text editor problem. It is a policy collision. Two branches are now shipping different definitions of how the agent should behave on every future ticket. Merging the file is making a policy decision about which behavior wins on every future session. I had been making that decision with my eyes closed, by hand, under deadline, on a file I thought was just notes.

The fetch/sync step that landed in the third ticket’s session is a good example of why this matters. That step runs before branch creation and verifies the clone’s remote state. It was added to prevent the agent from cutting a branch on a stale base. That was intended as a safety invariant for future tickets, not just the one that revealed it. Once present in the shared skill, it could influence any session configured to use that version. Putting it in on a feature branch and not thinking about whether it conflicts with anything on the hotfix branch in flight is exactly the kind of casual editing that creates real problems at merge time.

The blast radius of a skill edit is every future ticket session that runs on a clone with that version of the file. A prompt file with that blast radius is not soft configuration. It is a policy file, and it deserves the same change-control caution as the code it orchestrates.

what changes now

The immediate fix was mechanical but not merely textual: resolve the conflict, read both sides of the diff carefully, and write a merged version that retained the customer-priority, role-disambiguation, and deferred-branch-creation changes. The result was a clean merged policy decision.

The structural change is slower. I’m now treating edits to .claude/skills/ticket/SKILL.md the way I’d treat edits to the JIRA workflow configuration or the CI pipeline. They happen on a branch with intention. They get reviewed before merge. They don’t get patched casually as a side effect of ticket work. If a ticket session reveals a skill gap, the fix goes into a tracked commit with a note, not an ambient edit that blurs into the ticket’s history.

The open question from that day is still open: should the skill be split into a stable policy layer and a per-ticket behavior layer, so local work can adapt without changing a shared workflow file? I did not have an answer yet. The conflict made the key point clear: when prompt files shape repeatable automated work, they deserve infrastructure-grade change discipline.