Observed while running check-skill-line-ratchet for PR #15955 (the readings-ledger increment). Filed bare — priority and lane are triage's. Recording only, no severity asserted. Pre-existing on origin/main: the same line is printed by a run of the gate at a2051fa4e9, so nothing in that PR caused it.
The reading
Every run of pnpm check:pm-skill-ratchet prints this advisory, and has been printing it for some time:
ℹ️ .claude/skills/spec-property-retirement/SKILL.md: max-table-row-bytes headroom is 2 — every pin is seeded at 0 headroom, so a row has been paid down; lower the pin to 326 (shrink-only ratchets tighten opportunistically).
The pin is 328; the widest table row in that file is now 326 bytes. Two bytes of slack have been paid down by some earlier edit and never reclaimed.
Why it is worth a card rather than leaving it to the next reader
The gate is doing exactly what it is designed to do — a shrink-only ratchet is supposed to tighten opportunistically, and it names the new value for you. But an advisory that prints on every run and is acted on by no run is indistinguishable from noise after a while, and it trains readers to skim the gate's output. The two bytes are worth nothing; the habit is worth something.
Suggested direction, not prescribed
Lower the max-table-row-bytes pin for .claude/skills/spec-property-retirement/SKILL.md from 328 to 326 in scripts/pm/check-skill-line-ratchet.mjs. Lowering a shrink-only pin is always legitimate and needs no ruling. .claude/** is a governed surface, so it lands as a draft PR with a human merge like any other — which is the whole reason it is worth batching with the next edit to that script rather than spending a PR on two bytes by itself.
Dedup
Searched before filing. /search/* is 403 on this session (the proxy serves repository-scoped paths only), so the check went through the repository-scoped list endpoint plus a local grep: 189 open finding cards and 32 open domain:skills cards, grepped for max-table-row, table-row-bytes, spec-property-retirement, 326 and 328. No match.
Generated by Claude Code
Generated by Claude Code
Observed while running
check-skill-line-ratchetfor PR #15955 (the readings-ledger increment). Filed bare — priority and lane are triage's. Recording only, no severity asserted. Pre-existing onorigin/main: the same line is printed by a run of the gate ata2051fa4e9, so nothing in that PR caused it.The reading
Every run of
pnpm check:pm-skill-ratchetprints this advisory, and has been printing it for some time:The pin is 328; the widest table row in that file is now 326 bytes. Two bytes of slack have been paid down by some earlier edit and never reclaimed.
Why it is worth a card rather than leaving it to the next reader
The gate is doing exactly what it is designed to do — a shrink-only ratchet is supposed to tighten opportunistically, and it names the new value for you. But an advisory that prints on every run and is acted on by no run is indistinguishable from noise after a while, and it trains readers to skim the gate's output. The two bytes are worth nothing; the habit is worth something.
Suggested direction, not prescribed
Lower the
max-table-row-bytespin for.claude/skills/spec-property-retirement/SKILL.mdfrom 328 to 326 inscripts/pm/check-skill-line-ratchet.mjs. Lowering a shrink-only pin is always legitimate and needs no ruling..claude/**is a governed surface, so it lands as a draft PR with a human merge like any other — which is the whole reason it is worth batching with the next edit to that script rather than spending a PR on two bytes by itself.Dedup
Searched before filing.
/search/*is 403 on this session (the proxy serves repository-scoped paths only), so the check went through the repository-scoped list endpoint plus a local grep: 189 openfindingcards and 32 opendomain:skillscards, grepped formax-table-row,table-row-bytes,spec-property-retirement,326and328. No match.Generated by Claude Code
Generated by Claude Code