make-git-commit

name	make-git-commit
description	Use this skill when creating a Git commit. Follow the Conventional Commits 1.0.0 specification, write a short imperative subject, keep the body concise and factual, and never add a co-author trailer for Claude, Claude Code, or any other agent.

Run git status and git diff --staged before composing the message, so the subject and body describe what is actually staged and not what was planned.

Stage files explicitly with git add <path>; do not run git add -A, git add ., or git commit -a, because those sweep in unrelated changes and leak secrets.

Format the subject line as <type>(<scope>): <description> per the Conventional Commits 1.0.0 spec at https://www.conventionalcommits.org/en/v1.0.0/, where the scope in parentheses is optional and the colon-space separator is mandatory.

Prepend the related ticket number with a leading hash sign to the description (fix(parser): #123 handle empty input) whenever the commit is tied to a known issue or pull request, so the subject links the change to its tracking ticket; omit the prefix only when no ticket applies.

Pick the type from the standard set: feat for a new feature, fix for a bug fix, docs, style, refactor, perf, test, build, ci, chore, or revert; do not invent new types.

Append ! after the type or scope (feat!: or feat(api)!:) and add a BREAKING CHANGE: footer when the commit introduces an incompatible change, so tooling can detect the break from the subject alone.

Write the description in the imperative mood, lowercase, with no trailing period, under 72 characters (fix(parser): handle empty input, not Fixed the parser.).

Leave one blank line between the subject and the body, and another blank line between the body and any footer; the parser relies on these blank lines to split the message.

Keep the body to a few short sentences that explain the motivation and the visible effect, wrap lines at 72 columns, and omit the body entirely when the subject already says everything.

Do not add a Refs: footer when the subject already carries the #<number> prefix, because the reference is already visible and a second mention is noise; add a Closes #<number> or Fixes #<number> footer only when the host needs that exact token to auto-close the ticket on merge.

Never add a Co-authored-by: trailer naming Claude, Claude Code, Anthropic, or any other coding agent; the commit is authored by the human running the agent and attribution to a tool is misleading.

Never override the author or committer on the command line with --author, -c user.name=, -c user.email=, GIT_AUTHOR_NAME, or GIT_COMMITTER_EMAIL; rely on the defaults configured in the repository or the user's global Git config so the commit is attributed correctly.

Never add promotional trailers, signatures, emoji, or "Generated with" lines to the message; the commit log is a technical record, not a credit screen.

Do not pad the message with restated diffs, file lists, or obvious summaries (updated foo.js to add a function); the diff already shows that — the message must add the reason.

Do not bundle unrelated changes into one commit; split by intent so each commit has one type, one scope, and one reviewable purpose.

Do not pass --no-verify, --no-gpg-sign, or any flag that bypasses hooks or signing unless the user has explicitly asked for it; a failing hook means the commit is not ready.

Pass the message via a HEREDOC to git commit -F - or git commit -m "$(cat <<'EOF' ... EOF)" so blank lines, backticks, and quotes survive the shell intact.

After the commit, run git log -1 --stat to confirm the subject, body, footers, and file set match the intent; if anything is wrong, create a new commit rather than amending the previous one.