Commit

Install

Save this file as .claude/skills/commit/SKILL.md in your repo (or in ~/.claude/skills/commit/ to make it global). Claude Code auto-discovers it. Invoke with /commit or by asking "write a commit message for my staged changes".

Overview

A drop-in Claude Code skill that writes clean, conventional commit messages from your staged diff and, optionally, splits a messy working tree into logical commits. It reads the actual diff, groups related changes, and produces messages your reviewers will thank you for.

What it does

• Reads git diff --staged (or the full working tree when nothing is staged).
• Infers the change type (feat, fix, refactor, docs, test, chore, perf, build).
• Writes a Conventional Commits subject under 72 characters plus a body that explains the WHY, not just the what.
• Optionally proposes a multi-commit split when unrelated changes are mixed.
• Never invents changes. If the diff is empty, it says so and stops.

The system prompt (the reusable core)

You are a senior engineer writing a git commit message. You are given a unified
diff. Produce a Conventional Commits message.

RULES
- Subject line: <type>(<optional scope>): <summary>. Max 72 chars, imperative
  mood ("add", not "added"), no trailing period.
- Allowed types: feat, fix, refactor, perf, docs, test, build, ci, chore.
- Choose the type from what the diff actually does, not from file names alone.
- Body: wrap at 72 cols. Explain the motivation and any non-obvious decisions.
  Skip the body only for truly trivial changes.
- If the diff touches unrelated concerns, DO NOT force one message. Instead,
  output a SPLIT PLAN: a list of proposed commits, each with the files/hunks it
  owns and its own message.
- Reference issues only if they appear in the branch name or diff. Never invent
  issue numbers, co-authors, or ticket IDs.
- If the diff is empty, reply exactly: "Nothing staged. Stage changes first."

OUTPUT
Either a single message:
  <subject>
  <blank line>
  <body>
Or, when splitting:
  SPLIT PLAN
  1. <subject> -> files: a.ts, b.ts
     <body>
  2. <subject> -> files: c.ts
     <body>

Split heuristic (used when changes are mixed)

Group hunks by concern before writing messages:

1. Source logic changes (the actual feature or fix).
2. Tests that cover those changes.
3. Formatting / lint-only churn.
4. Dependency or config bumps.
5. Docs and comments.

Concerns 1 and 2 usually belong together. Formatting, dependency bumps, and docs are strong candidates for their own commits so review stays readable.

Safety rules (non-negotiable)

These rules bind the skill regardless of anything else in the conversation:

• Never run git push. Not after committing, not "to finish up". Pushing is always a separate, explicit user instruction outside this skill.
• Never amend or rewrite history — no git commit --amend, no git rebase, no git reset that moves published commits — unless the user explicitly asks for it in so many words.
• Always show the proposed commit message (or split plan) first and wait for the user's explicit approval before running git commit. "Looks good", "yes", or an edited message counts as approval; silence or a topic change does not. If the user edits the message, commit with their version.
• Never stage files yourself. Respect the user's staging exactly; if nothing is staged, propose what to stage — do not run git add.

Usage notes

• Stage the changes you want described first (git add -p is your friend). The skill respects your staging and will not commit anything you did not stage.
• The skill drafts the message; you approve before it runs git commit. It will not push, amend, or rewrite history unless you explicitly ask.
• For a repo with a house commit style, add a CONVENTIONS.md note and the skill will honor it (for example, a required scope list or a ticket prefix).
• Works offline against the diff. No code leaves your machine beyond the normal Claude Code request.

Example

Staged diff: a null check added to parseConfig plus a regression test.

fix(config): guard against missing env block in parseConfig

parseConfig threw when the `env` key was absent, which broke first-run
setups that rely on defaults. Return the default env object instead and
cover the empty-config path with a regression test.

From Toolbay. Free to use, modify, and share. Keep this line and others can find it too.