Git Commit Methodology
Each commit records one independently correct decision: what changed, why, and how to understand/revert it without surrounding context. Write at seventh-grade, STE-flavored level; call the Skill tool with writing-prose and apply ## Self-lint before finalizing.
The 50/72 Rule
- Subject: under 50 characters, imperative, specific, first word capitalized after any type prefix, and no final period. Complete “This commit will…”.
- Body: blank line after subject, wrap at 72 characters, explain motivation and non-obvious caller, migration, or compatibility effects. The diff already shows what changed.
Conventional Commits
Use <type>[optional scope]: <description>, optional body, then optional footers. Allowed types: feat, fix, refactor, test, docs, chore, perf, ci, revert. Scope names the component/module/layer, e.g. feat(auth):, fix(api):, docs(readme):.
Breaking changes require a BREAKING CHANGE: footer or ! in feat!: / feat(api)!:. Read references/formats-and-examples.md when choosing a type, scope, or breaking-change form.
Atomic Commits
- One logical change per commit; “and” in the subject often signals two commits.
- Every commit leaves tests passing; never rely on a later commit to repair it.
- Stage selectively with
git add -p when one file contains unrelated hunks.
Ship-phase commit
- Summarize the complete user-visible feature, not implementation steps.
- Briefly list important affected files/subsystems in the body.
- Cite the issue or plan:
Closes #42 or Implements docs/plans/2026-01-15-auth-plan.md.
- Omit attempts, WIP notes, and details evident from the diff.
Complex changes need a body. Squash every WIP: still debugging commit before shipping.
1---2name: git-commit3description: Defines Conventional Commit subjects and safe commit procedure. Load before creating or reviewing commits.4---56# Git Commit Methodology78Each commit records one independently correct decision: what changed, why, and how to understand/revert it without surrounding context. Write at seventh-grade, STE-flavored level; call the Skill tool with `writing-prose` and apply `## Self-lint` before finalizing.910## The 50/72 Rule1112- Subject: under 50 characters, imperative, specific, first word capitalized after any type prefix, and no final period. Complete “This commit will…”.13- Body: blank line after subject, wrap at 72 characters, explain motivation and non-obvious caller, migration, or compatibility effects. The diff already shows what changed.1415## Conventional Commits1617Use `<type>[optional scope]: <description>`, optional body, then optional footers. Allowed types: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`, `perf`, `ci`, `revert`. Scope names the component/module/layer, e.g. `feat(auth):`, `fix(api):`, `docs(readme):`.1819Breaking changes require a `BREAKING CHANGE:` footer or `!` in `feat!:` / `feat(api)!:`. Read [references/formats-and-examples.md](references/formats-and-examples.md) when choosing a type, scope, or breaking-change form.2021## Atomic Commits2223- One logical change per commit; “and” in the subject often signals two commits.24- Every commit leaves tests passing; never rely on a later commit to repair it.25- Stage selectively with `git add -p` when one file contains unrelated hunks.2627## Ship-phase commit28291. Summarize the complete user-visible feature, not implementation steps.302. Briefly list important affected files/subsystems in the body.313. Cite the issue or plan: `Closes #42` or `Implements docs/plans/2026-01-15-auth-plan.md`.324. Omit attempts, WIP notes, and details evident from the diff.3334Complex changes need a body. Squash every `WIP: still debugging` commit before shipping.
bostonaholic