--- name: commit description: Write a Conventional Commits message from the staged diff, or split a messy working tree into logical commits. Use when the user asks to commit, write a commit message, or clean up the working tree before committing. --- # 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: ():

. 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: Or, when splitting: SPLIT PLAN 1. -> files: a.ts, b.ts 2. -> files: c.ts ``` ## 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. ```