---
title: "Enforcing a Writing Standard Across 927 JIRA Tickets"
canonical: https://dxdev.com/blog/2026-09-12_writing-standard-enforcement-scale/
datePublished: 2026-09-12
---
The hooks went in clean. The 927 tickets didn't.

We'd just finished the actual engineering: a writing standard for JIRA comments, plus pre-commit hooks that enforce it going forward. No more comments that narrate the diff instead of explaining why the code does something surprising. No more three-paragraph essays where a fact and a warning would do. The hook checks new commits against the standard before they land. That part took an evening.

Then someone ran the standard against what already existed, and it came back for all 927 open tickets. Every one of them predated the hook by definition, so every one of them violated it. Years of ticket-comment style drift, live at once.

## Why a hook can't retrofit anything

A pre-commit hook only sees the commit in front of it. It has no opinion about history, and it shouldn't, because rewriting JIRA comment history isn't a git operation. Comments live in JIRA's own store, tied to ticket state, workflow transitions, sometimes customer-visible fields. There's no `git rebase` for that. The fix had to be a sweep: pull every open ticket's comment body, run it through the same judgment the hook applies to new commits, rewrite in place through the JIRA API.

The instinct was to just point the same checker script at all 927 and let it run. That was the wrong turn, and it cost about twenty minutes of watching a batch job silently do the wrong thing. The hook's checker was written to flag violations and reject a commit. It was never written to *fix* a violation, because in the hook's world the human fixes it and resubmits. Pointed at a backlog of 927 tickets with no human in the loop per ticket, it just flagged all 927 and sat there. Nothing shortened. Nothing shipped. I'd built a smoke detector and was trying to use it as a fire extinguisher.

## What actually worked

Two-pass judge setup instead. First pass: an agent reads each ticket's comment thread and proposes a shortened version, applying the same standard the hook checks for, but empowered to rewrite, not just flag. Second pass: a separate judge agent diffs the original against the proposed rewrite and looks for exactly one failure mode, a dropped fact. Not "is this shorter," not "does this read better." Specifically: did the rewrite lose a decision, a gotcha, a number, an ID, or a non-obvious reason that a future reader would need.

That second pass mattered because the first pass genuinely does this. Two logged runs against the same diff kept the same brief: flag instances where genuine implementation details, gotchas, specific numbers or IDs, or important context got dropped in favor of brevity. One flagged run caught a rewrite that had quietly dropped the `decision='multiteam'` condition under which a check gets skipped, the kind of thing a modifier six months from now would need and wouldn't get from the shortened text. Another caught a dropped detail about which asset references flip at release time. Both are exactly the kind of fact that's invisible until the person debugging at 2 a.m. needed it and it wasn't there.

Anything the judge flagged went back for a second rewrite attempt or got left alone rather than force-shortened. Anything it passed got applied.

## The count that mattered more than the total

927 tickets is the total. The number that actually tells you something is 38: comments long enough, or judged risky enough, that they got routed to a human review queue instead of auto-applied. Everything else, the other 889, went through the two-pass sweep and landed without a person reading it first.

That ratio is the real output of the exercise. It's not "we automated ticket cleanup." It's that a standard enforced only at the point of creation guarantees a debt pile the size of your entire open backlog, and the size of that pile is exactly the fraction of your history that predates the rule. The hook stops the bleeding. It does nothing about the wound already there. If you're adding one of these, budget for the backlog sweep before you turn the hook on, because the hook's existence is what tells you, precisely, how much backlog you have.