The same person, the same tracker. The difference was who drafted the text.
Why this exists
Once agents started drafting my ticket comments, pull request descriptions and commit messages, the text got longer. I measured it. Over three months, my ticket comments had a median of 74 words. In the two weeks of heaviest agent use, single comments reached 755 words, and several were multi-paragraph prose with no bullets at all. Over half of my pull request titles were longer than 70 characters; the longest was 142.
None of it was wrong. It was accurate, polite and complete. It was also too long for the people who had to read it, and most of them read English as a second language. A reviewer's time went into finding the one line that mattered.
1. Name the reader first
The written standard starts with the audience, not the format: a colleague who reads English as a second language, scanning a ticket days later, who was not there when the work happened. Clarity beats completeness. Short sentences, plain words, active voice, a number or an identifier instead of an adjective. No idioms, no scene-setting, no closing sentence that repeats what was just said. Every other rule follows from that reader.
There is a second reader: the next agent. Before an agent starts on a ticket, it reads the issue and every comment on it. A padded comment costs it what it costs a person: it has to read past the story to find where the work stands. A comment that opens with the conclusion and ends with what is still open is the best starting point a new session can get.
Fixed: archived projects are in the export again.
- Cause: a filter ran before the archive flag was read.
- A failing test proved it; it passes now.
- Checked on staging with three archived projects.
Release note for the next version.
A colleague
Days later, between other work, often in their second language. Finds what to do next in the first line.
The next agent
Reads the issue and every comment before it starts. Starts from the conclusion, not from last week's story.
Every ticket comment has two readers. The example is made up; the shape is the standard.
2. A shape and a limit for each kind of text
"Be concise" does not work as an instruction, for people or for agents. A fixed shape does:
- Ticket comment: one line with the conclusion, two to five bullets of evidence, one line naming what is still pending.
- Ticket description: issue, cause, what confirmed it, the fix, then a checklist of work still to do.
- Pull request description: three to five bullets on what changed and why. About 900 characters; 2,500 is the outer limit.
- Review comment: one short bullet per finding. Five findings are five bullets, not five paragraphs.
- Commit message: one line, no body, no tool attribution.
3. The main failure: pasting the chat explanation into the ticket
Most of the length came from one habit. An agent explains its work in the chat, in order, for someone following along. That explanation is good for its purpose, so it gets reused as the ticket comment. But a ticket comment is read later, out of order, by someone who was not in the session. A chat explanation used as a ticket comment reads like a session summary.
The rule: draft the ticket text separately, then check it. Count the sentences. If it reads like a findings list with one sentence per item, or like a summary of the session, cut it. Then ask whether a reviewer who has never seen the branch would act differently after reading it. If not, do not post it. And an agent asks before it posts a ticket comment at all.
4. Find the real lever: long titles were not a typing problem
Long pull request titles matter because a squash merge turns the title into the permanent commit subject. It then appears in every log, every blame and every release note, and cannot be fixed later. But telling agents to write short titles changed nothing, because the title was not ours to set. In the repository in question, a workflow rewrites every new pull request title from the ticket's type, ID and summary seconds after it opens.
So the limit belongs on the ticket summary. Every summary carries 31 to 35 characters of machinery into the commit subject: the type prefix, the ticket ID, a separator and the pull request number the squash merge appends. My first two limits, 55 and then 39, were both worked out from a 70-character subject limit. Recounting real subjects showed the flaw: nothing enforces 70, and more than half the subjects in the repository were already past it. The median summary was 47 characters. The problem was the long tail, with the longest tenth over 100. The rule now: aim for 50 characters, never go past 60, and never shorten a summary into something cryptic just to hit a number. That is the worse failure.
5. Put the rules where every agent reads them
The standard lives in two places: the project's own agent guide, which every agent reads at the start of a session, and my personal instruction file, which applies in every repository I work in. It is not a style preference someone has to remember. It is loaded before the first word is written.
What this buys
Shorter text is not the goal. A reviewer's time is. Agents are very good at producing text that is correct and complete, which is exactly why they need a limit: nothing in the text itself signals that it is too long. This page is longer than any ticket comment the standard allows. It is not a ticket comment.