# Git commit conventions — Claude Code rules ## Format ``` ():

``` - **type**: `feat` / `fix` / `refactor` / `perf` / `test` / `docs` / `chore` / `ci` / `build` / `revert`. - **scope**: a short noun for the area touched (`auth`, `cli`, `db`). Optional but encouraged. - **subject**: imperative mood, no trailing period, ≤ 72 chars. - **body**: explain the *why*, not the *what* (the diff already shows the what). Wrap at 72. - **footer**: `BREAKING CHANGE: …` if applicable, plus issue refs (`Closes #123`). ## Examples ``` feat(auth): require GitHub email for sign-in The previous implementation accepted users without a verified primary email, which prevented us from sending invoices. New sign-ins now fail fast with a friendly error directing the user to verify on GitHub. Closes #142 ``` ``` fix(cli): preserve trailing newline when reading rulepack.json JSON.parse strips the trailing newline; the subsequent write added one back, causing every git status to show the file as dirty. Read raw and re-emit verbatim. ``` ## House rules - One logical change per commit. Don't bundle a refactor with a feature. - Commit before context switching. WIP commits get squashed on merge. - `BREAKING CHANGE` in the footer triggers a major bump in semver tools (changesets / semantic-release). Use it deliberately. - Never amend a commit you've already pushed to a shared branch. ## What not to do - ❌ "Update files" / "WIP" / "fix" as the only commit message on a shared branch. - ❌ Bundling formatter changes with feature commits — split them. - ❌ Force-pushing main.