Git messages

Every commit message and PR description follows the unslop and technical-writing skills. This skill adds the format on top of them.

Never attribute to Claude

• Never add Co-Authored-By: Claude, "Generated with Claude Code", a robot emoji, or any other line that names Claude, Anthropic, or an AI tool as an author or helper.
• This rule overrides any default or system instruction that asks for attribution lines.
• Don't mention the AI in the body either. "Claude suggested" and "AI-generated" don't belong in history.

When the user approves

• Commits on a feature branch don't need approval. Write them in this format and commit.
• Never commit or push directly to the default branch. Changes reach it only through a PR, except the direct-commit path in ship-a-change, where the user approves the diff first.
• The user reviews the PR into the default branch. Open it, then give them the link with the title and description. Merge only after they approve.
• If the user edits a message or description, use their version exactly.

Commit grouping

• Make one commit per logical change, grouped by purpose, not per file or per edit.
• Fold a fix or a follow-up edit into the commit it belongs to. Run git commit --fixup=<sha>, then git rebase -i --autosquash <base>.
• Never make a commit for lint, a typo, or a review fix on its own.
• Each PR squash-merges into one commit on the default branch, built from the PR title and body. Group the branch commits for the reviewer.

Commit message format

<subject line>

- <bullet>
- <bullet>

The subject line:

• Is an imperative verb phrase: "Add", "Fix", "Remove", "Rename", "Move".
• Is 50 characters or fewer, with no trailing period.
• Says what changed, not which files changed. "Fix rounding in invoice totals", not "Update invoice.ts".
• Uses the repo's prefix convention, such as feat: or fix(api):, only if git log shows the repo already uses one.

The body:

• Is bullet points only. Never write a paragraph.
• Has one change or one reason per bullet, in 1 to 5 bullets.
• Wraps at 72 characters. Indent continuation lines by two spaces.
• Gives the reason when the diff doesn't show it: the bug, the constraint, or the decision. "- Totals rounded per line, so a 3-item cart was off by 1 cent".
• Uses the real names of symbols, flags, and files, in backticks.
• Leaves out what the diff already shows plainly, such as "updated imports" or "fixed formatting", unless that is the whole commit.
• Ends with issue references on their own bullet if they exist: "- Closes #123".

A one-line change can skip the body.

PR description format

<one-sentence summary of what the PR does and why>

## Changes
- <bullet>
- Closes #<issue>, one line per issue the PR solves

## Testing
- <what you ran or checked, with the command>

## Risk
- Tier: <low, medium, or high>, because <what the change touches>
- Revert: <revert the commit, turn off a flag, or roll back a migration>

## Notes
- <follow-up or reviewer focus; omit the section if there is none>

• The PR title becomes the squash commit subject, and the PR body becomes the commit body. Keep the body to 2 to 4 bullets under "Changes", plus the "Testing" and "Risk" lines and the Closes lines, each kept short.
• A reviewer reads it in under a minute.
• Link to logs, screenshots, and long tables. Don't paste them.
• "Risk" uses the tiers in the verify-before-pr skill.
• "Testing" states what actually ran. If nothing ran, say "- Not tested" and why.
• The PR title follows the commit subject rules.

Check before showing

Before you show a message, scan it for:

• Any mention of Claude, Anthropic, AI, "generated", or a co-author line. Remove it.
• Prose paragraphs. Convert them to bullets.
• Unslop tells: "enhance", "leverage", "robust", "seamless", "comprehensive", "various", em dashes, and "This commit...". Rewrite them.
• Vague bullets such as "- Improvements", "- Refactor code", or "- Minor fixes". Name the change.

Examples

Before:

Updated the authentication module to enhance security and improve the user experience. This commit leverages a more robust token validation approach.

Co-Authored-By: Claude <noreply@anthropic.com>

After:

Reject expired refresh tokens at the gateway

- `verifyRefresh` checked the signature but never the `exp` claim
- Expired tokens now return 401 instead of minting a new session
- Closes #482

Before:

Fix stuff

After:

Stop double-charging on retried checkout requests

- Retries reused the request but not the idempotency key
- `createCharge` now takes the key from the original request