Skip to content

source-control:commit: composition policy is ambiguous and decays; hub outgrows the compaction re-attach window #1583

Description

@kyle-sexton

Problem A — "compose by natural-language reference" is ambiguous

The skill says other skills should compose /commit "by natural-language reference rather than
invoking git directly". That phrase is ambiguous between two very different things:

  1. re-invoking /commit per commit, and
  2. having absorbed the convention once and thereafter following it from memory.

Reading (2) is economically rational for a session making many commits, and it is what actually
happens. Re-invocation appends the skill's full content again whenever the rendered content differs —
and the pre-computed dynamic-context lines differ every time, so every re-invocation is a full
re-append (https://code.claude.com/docs/en/skills, "Skill content lifecycle", fetched 2026-07-26).

The failure this produces is specific and observed: the message SHAPE survives memory-following,
because it is reinforced visibly every commit. The ordered per-commit CHECKS do not.
The formatter
run, the exec-bit fix, and the subject pre-check produce no visible signal when skipped, so a session
that has stopped running them looks identical to one that has not — until CI says otherwise (#1579).

Problem B — the hub does not fit the compaction re-attach window

Auto-compaction re-attaches only the first 5,000 tokens of each invoked skill, with a
25,000-token combined budget across skills, filled most-recent-first
(https://code.claude.com/docs/en/skills, "Skill content lifecycle", fetched 2026-07-26). At 266
lines with roughly 130 of them being pathspec/hide-restore and format-check edge machinery, the hub
spent its window on the ~20% path and pushed the exec-bit and pathspec sections — the per-commit
checks — into the region that gets dropped first.

The skills page also states the general guidance directly: "Keep SKILL.md under 500 lines. Move
detailed reference material to separate files", and "Once a skill loads, its content stays in
context across turns, so every line is a recurring token cost."

Problem C — config-ladder resolution is unobservable

Nothing surfaces which of the three config layers are present, so a skipped resolution is invisible
to the user and to the session.

Trap for whoever implements C: the probe must test tracked-ness, not existence. Version
0.25.1 established that the tracked-team layer must be git-tracked (git ls-files --error-unmatch)
precisely so an untracked or gitignored file at the well-known path cannot drive resolution. A naive
test -f probe would reintroduce that bug in the pre-computed context, making the drafting surface
disagree with the enforcement surface again.

Fix

  • A: define composition as exactly two named forms — re-invoke /commit, or run the per-commit
    checklist yourself as commands — and state that "remembered convention" is neither. Name the checks
    as the thing that decays, and why.
  • B: split the format-check, pathspec-commit, exec-bit, and staging-precondition machinery into
    reference/ spokes with load-when pointers; reorder so the per-commit checklist and staging rules
    sit at the top, ahead of reference rationale.
  • C: pre-computed probes of all three config layers, reporting an untracked team file as
    present but UNTRACKED — not a config layer rather than as a layer.

Plus a compact per-commit checklist near the top of the hub as the cheap re-anchor for both A and B.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-triageNot yet classified. Floor until a type and one priority tier are set.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions