commit

Optional argument: a target file or chunk. Commit only that target.

1. Gather. Claude Code fills the snapshot below from the session's working
   directory when the skill loads. Run the commands yourself when they still show
   as raw ! commands, when you commit in another worktree, or when files changed
   after loading. Then diff only the files whose changes you still need to see.

   Status: !git status --short 2>&1 || true

   Unstaged: !git diff --stat 2>&1 | tail -n 30

   Staged: !git diff --staged --stat 2>&1 | tail -n 30

   Recent: !git log --oneline -5 2>&1 || true

2. Decide amend or new. Amend only when HEAD is not pushed to any remote and the change relates
   directly to it. Never amend a pushed commit. Make a new commit when none exist,
   HEAD is pushed, or the change has a different purpose or is a distinct unit.

3. Write the message per the Format section below. Use no emojis and no attribution,
   and keep secrets out of it. When you amend, keep the existing message unless the purpose
   of the commit changed.

4. Commit. Stage each chunk explicitly, including new and untracked files. Stage only
   the target when the user gave one. When one file spans multiple logical changes, follow
   partial-staging.md. Then run one of:

   • New commit: git commit -m '<message>'; use -F <file> if it has an apostrophe.
   • Amend, message unchanged: git commit --amend -C HEAD.
   • Amend, message changed (the commit's purpose changed): git commit --amend -m '<message>', or -F <file> as above.

   Fix the cause of any hook error and commit again. Never --no-verify a failing hook
   unless the user has said the failure is irrelevant to the change.

Format

<type>(<scope>): <description> — lowercase, imperative, no period, under 50 characters.

• Types: a11y, build, ci, deps, docs, dx, feat, fix, i18n, perf, refactor,
  revert, security, test, ux
• Repository conventions (commitlint config, AGENTS.md, CONTRIBUTING) override
  every default here: types, scope, ticket suffix, header length, breaking-change
  format
• Do not use chore or style unless those conventions require them.
• If the repo's type-enum lacks a type, map it:
  ux → feat; a11y and i18n → fix for a repair, else feat;
  security → fix; deps → build(deps); dx → build; refactor →
  chore. Map before writing, so commitlint does not reject the message
• Choose the type per Choosing the type below
• The scope is optional; include one when required
• Keep the description minimal, with no filler, and make it say why the change happened
• Add a body only when it gives context the description cannot hold

Choosing the type

Choose the type from the main purpose of the change. Supporting tests and docs
stay with that change and take its type. For a squash PR, consider the full diff.

• Product: fix repairs wrong behavior; feat adds a capability; ux changes
  intended behavior or appearance; perf improves performance with identical
  output; refactor preserves behavior. Use revert for an undo, security
  for closing an exploit, and a11y or i18n for accessibility or localization.
• Other areas: docs, test, ci, build, deps, or dx for developer
  tooling, including agent rules and skills. A docs-only PR is docs.
• Mark a breaking change with ! (feat!:, fix(api)!:) and a BREAKING CHANGE: footer
  describing the required migration.

When two types fit or the main purpose is unclear, read
choosing-type.md. Read its linked examples only
when a tie remains; routine commits do not need either reference.

Constraints

• Do not use git rebase -i, git add -i, or git add -p: they are interactive and cannot run here
• Do not create an empty commit
• Write temporary files in the scratch directory (AGENTS.md, Directories):
  a multi-line message, used with git commit -F <file>. Remove it after the commit succeeds.