Summary
PR #71 merged with its first commit only; the follow-up commit that answered Codex's two P2 findings was pushed after the branch was deleted and never reached main.
Subtype
docs — Documentation
Context
Codex found two problems in #71 and both were fixed in commit 5155034, but gh pr merge had already squashed d730499 (merged 2026-09-16T08:05:30Z, branch deleted three seconds later), so the push recreated a dead branch and the replies on the review threads describe a fix that is not on main.
What main still says:
skills/branch-and-commit/SKILL.md rule 3 offers "a behaviour-changing refactor" as an example of a hidden-type change that should ship via Release-As. A refactor that changes behaviour is a fix or a feat, not a refactor — the example teaches the wrong type, which is the very mistake the paragraph is about.skills/release-management/SKILL.md rule 2 says the version bump is derived, never chosen, but the Release-As footer the same skill's pitfall recommends is a chosen version. The rule needs the exception stated, with its bound: X.Y.Z is always the current version plus one patch, and wanting more than a patch means the type was wrong (a hidden type also keeps the change out of the changelog).
The fix is the content of 5155034 re-applied on a branch from main. Docs only, hidden type, no release.
Acceptance criteria
Priority
p2 — Important, scheduled
Area
Summary
PR #71 merged with its first commit only; the follow-up commit that answered Codex's two P2 findings was pushed after the branch was deleted and never reached
main.Subtype
docs — Documentation
Context
Codex found two problems in #71 and both were fixed in commit
5155034, butgh pr mergehad already squashedd730499(merged 2026-09-16T08:05:30Z, branch deleted three seconds later), so the push recreated a dead branch and the replies on the review threads describe a fix that is not onmain.What
mainstill says:skills/branch-and-commit/SKILL.mdrule 3 offers "a behaviour-changingrefactor" as an example of a hidden-type change that should ship viaRelease-As. A refactor that changes behaviour is afixor afeat, not arefactor— the example teaches the wrong type, which is the very mistake the paragraph is about.skills/release-management/SKILL.mdrule 2 says the version bump is derived, never chosen, but theRelease-Asfooter the same skill's pitfall recommends is a chosen version. The rule needs the exception stated, with its bound:X.Y.Zis always the current version plus one patch, and wanting more than a patch means the type was wrong (a hidden type also keeps the change out of the changelog).The fix is the content of
5155034re-applied on a branch frommain. Docs only, hidden type, no release.Acceptance criteria
skills/branch-and-commit/SKILL.mdrule 3 no longer names a behaviour-changing refactor as a hidden-type example, and points at release-management rule 2 for the patch-only boundskills/release-management/SKILL.mdrule 2 states theRelease-Asexception and thatX.Y.Zis the current version plus one patch; the pitfall refers to rule 2 instead of restating the recipemake verifypassesPriority
p2 — Important, scheduled
Area