The 72-Character Subject Rule Cannot Survive the (#N) Suffix a Squash Merge Appends

[ptr727]

comment-and-doc-style's "PR titles and commit messages" states one shared contract:

an imperative subject, 72 characters or fewer, no trailing period

The fleet squash-merges, and GitHub appends (#N) to the merged subject. So a PR title that satisfies the rule at authoring time becomes a commit subject that violates it, and the rule gives no budget for the suffix.

Measured on this repository's own recent develop history:

Merged subject	Length
Review Hub Canonical Content Here, Before a Carrier Is the One to Read It (#1148)	81
Migrate the Hub's Unit-Test Step to Native Microsoft.Testing.Platform (#1107)	77

Both came from titles under 72. An agent writing a 70-character title satisfies the rule and ships a subject that does not.

What Settling It Needs

A decision rather than an edit, which is why this is filed rather than patched:

1. The 72 applies to the authored title, and the suffix is outside it. Then the rule says so, and a reader stops measuring merged history against it.
2. The 72 applies to the merged subject. Then the authoring budget is about 65 for a four-digit issue number, and the rule states that number rather than leaving each author to derive it.
3. The two surfaces get separate limits, since a PR title and a commit subject are different artifacts with different renderers.

Option 1 looks likeliest, since the suffix is GitHub's and not the author's, but the rule as written does not say it and the fleet's own history reads as a standing violation either way.

Provenance

Canonical-content review pass over .agents/skills/comment-and-doc-style/SKILL.md "PR titles and commit messages", run on the branch for #1078 and its sibling carried-text fixes. The two subjects above are from this repository's develop log.

Not This Issue

• #1078 is also against this unit, on the title-case example leaving devcontainer lowercase, fixed.

[ptr727]

One more in the same unit and the same rule family, from the second canonical-review round.

The lowercase bind-word list is not marked exhaustive or illustrative

US English spelling, and title case with lowercase short bind words (a, an, the, and, but, or, of, in, on, at, to, by, for, from)

The common short bind words the list omits (with, as, via, into, over, per) are the same length and class as the ones it names. An author writing Sync Skills with the Hub and a reviewer treating the list as closed and demanding With can both cite this rule, and nothing in the unit settles it.

It belongs with the subject-length question because both are the same shape: the rule states a precise-looking constraint that turns out not to decide the case in front of the reader.

[ptr727]

Maintainer decision, 2026-09-07: option 1. The 72 applies to the authored title, and the squash
suffix sits outside it.

The decision turned on whether 72 is a hard limit anywhere. It is not, and that was checked rather
than assumed before deciding:

• No commit-msg hook exists. .husky/ carries pre-commit and pre-push only.
• No workflow or script gates subject length. Nothing under .github/workflows/ or scripts/
  measures a subject or title.
• The 72 is the git log readability convention, which leaves room for the four-space indent git
  adds when rendering a subject in an 80-column terminal.

Since nothing rejects a longer subject, budgeting the authored title down to roughly 65 to reserve
room for a suffix GitHub appends would trade real title clarity for a limit no tool enforces. So the
rule states that the 72 measures the authored title, and that the (#N) a squash merge appends is
outside it, which also stops a reader measuring merged history against the rule and finding a
standing violation that is not one.