---
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.