Commit with a reviewed message

Draft a commit message for the current changes, show it to the user, and commit only after they approve it. Never commit without an explicit OK.

Hints from the user (may be empty): $ARGUMENTS

1. Look at the changes

git status --short
git diff --cached --stat
git diff --cached

• If something is staged, the commit covers only the staged changes. Mention unstaged or untracked files, but don't add them.
• If nothing is staged, propose which files to stage (group them by one logical change) and include that list in the preview. Stage them only after the user approves.
• If the changes contain several unrelated changes, suggest splitting them into separate commits, one preview each.
• Read the diff itself, not just file names, so the message says what changed and why.

2. Write the message

<type>[(<scope>)]: <subject>

<body>

Subject line

• <type> is one of:

  type	for
  feat	A new feature
  fix	A bug fix
  docs	Documentation only changes
  style	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
  refactor	A code change that neither fixes a bug nor adds a feature
  perf	A code change that improves performance
  test	Adding missing tests or correcting existing tests
  build	Changes that affect the build system or external dependencies (pnpm, Turborepo, tsc build, package.json)
  ci	Changes to the CI configuration files and scripts (GitHub Actions workflows, .github/actions)
  chore	Other maintenance that changes no source or tests (.gitignore, repo settings)

• <subject>: one short sentence in the imperative mood (present tense, written as an order: add, fix, remove, not added / adds), lower case, no period. This follows Google's CL description guidelines: the first line is a short, focused summary that reads as an order.

• <scope> is optional. Add it only when the change is confined to one package or area, using its directory name: biome-config, nextjs, api, react-native. Leave it out for changes that span several packages or the whole repo.

• The whole line, including <type>(<scope>): , is 50 characters or fewer. Drop the scope if it would push the line over.

• Examples: feat: add new page, fix(cli): report missing token key

Body

• Leave one empty line after the subject.
• Two or three sentences at most, in the past tense (Added …, Replaced …, Fixed …): what changed, and why (the problem it solves). Mention a file, export or option name in backticks when it helps.
• Avoid overly verbose descriptions or unnecessary details (no file-by-file lists, no restating the diff).
• Wrap lines at 72 characters.

3. Preview

Show the user, and then stop and wait for their answer:

Files to commit:
  M  path/to/file.ts
  A  path/to/new-file.ts

```
feat: add variants to createThemedStyles

Added a `variants` option so one style factory can return several
named variants. Each variant is resolved with the current color mode.
```

Commit with this message? Reply "OK", or tell me what to change.

• OK (or any clear approval) → go to step 4.
• A change request ("make it fix", "shorter", "mention X") → rewrite the message and show the preview again. Repeat until approved.
• Cancel → stop without committing.

4. Commit

Pass the approved message exactly as previewed. Don't append a Co-Authored-By trailer or any other footer:

git commit -F - <<'MSG'
<approved message>
MSG

• Lefthook's pre-commit hook runs Biome (and may restage fixed files) and tsc for the touched packages. Never bypass it with --no-verify.
• If the hook fails, show the error, fix the cause if it is clear (or ask), and preview again before retrying.
• Afterwards, reply with the commit hash and subject (git log --oneline -1).