/commit
The reference slash command for writing Conventional Commits from real git state. Matches your team's existing style, splits unrelated concerns, and pays back its authoring cost in the first working afternoon.
/commit is the single most-installed slash command in every survey we've run. That's not surprising: git commits are the most frequent repetitive-shape operation in software work, and codifying them into a well-designed slash command pays back its authoring cost inside the first working session.
The reference implementation on this page does three things a naive commit prompt wouldn't. It reads real git state before writing (via git diff --cached --stat and git log --oneline -5) so the message reflects what's actually staged, not a plausible guess. It matches your team's existing commit style by inspecting recent commits — scope prefixes, all-lowercase, emojis, whatever your team already does. And it refuses to lump unrelated concerns, proposing to split when the diff spans two topics rather than shipping a mixed commit.
If you install exactly one slash command from this entire site, install this one.
The full /commit definition
Copy this file to .claude/commands/commit.md in any git repo and it's ready to use.
How to install
Choose the scope you want. Project scope is what most teams use because it commits into git and every teammate gets the same command.
Project scope Recommended
Save as .claude/commands/commit.md at the root of your repo. Commit the file. Every teammate gets the command on next pull. Zero-config onboarding.
User scope Personal
Save as ~/.claude/commands/commit.md. The command works across every project you touch, with your personal defaults. Skip for team standardization; use for personal preferences.
Both scopes
Project scope wins on conflicts. Common pattern: user-scope /commit as your personal default, then project-scope override for repos with unusual commit conventions (all-caps type, specific scope taxonomy, required footer).
How to use it
The command works with or without staged changes and takes an optional focus argument.
.env files) and asks before continuing.$ARGUMENTS value focuses the commit message on that area. Especially useful when the diff touches multiple areas but you want the message to emphasize one — e.g., an auth change plus incidental style tweaks.BREAKING CHANGE: footer if the diff supports it./commit writes and commits, /pr-create uses the branch diff (including your fresh commit) to open a PR with a generated title and description.Alternative configs
Alternate configurations for teams with specific conventions.
type(scope): formattype(scope): subject. Infer scope from the top-level changed directory (e.g., feat(auth), fix(api)). If unsure, ask before committing."feature/JIRA-123-description). Append as [JIRA-123] at end of subject."Pairs well with
The full commit-and-ship workflow benefits from all three of these installed together.
Common issues and fixes
The four issues teams report most often, with fixes.
git log inference. Example: "Use lowercase type prefix, no scope, no trailing period. Subject in present-tense imperative." Explicit rules beat pattern-matching every time.!`git rev-parse --abbrev-ref HEAD` in Context. If you see the wrong branch in the output, either restart the session or explicitly run git status first to force a refresh.Other git workflows items
Same category, different job.
🐛 Hit an error?
AI Error Hub covers Claude Code errors and stack traces — cross-referenced with everything on this site.
Frequently asked questions
The questions developers ask most about /commit.
Because git commits are the highest-frequency repetitive-shape operation in software work. Every project has them, they happen many times per day, and getting them consistent across a team is high-value.
That's the textbook slash-command pattern. The authoring cost pays back inside the first afternoon.
It reads the last five commits via git log --oneline -5 as part of the Context section. The rule "match the team's existing commit style from the recent-commits list" is embedded in the task body.
If your team uses lowercase, scope prefixes, or gitmoji, the new commit follows. Style is learned per-project, not hardcoded.
The command auto-stages unstaged changes that look intentional — files that aren't lockfiles, generated artefacts, or .env files. It asks before actually committing so you can veto the auto-stage.
If you want stricter behavior, change rule 1 to "list unstaged files and ask which to stage" rather than auto-staging.
A narrow git subset:
Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*), Bash(git log:*), Bash(git rev-parse:*)
Do not give it general Bash access — a commit command should never be able to run rm or curl. Narrow allowed-tools is the primary safety mechanism.
Not in the reference config, and not recommended. A slash command that pushes is one Claude misinterpretation away from a bad state (wrong branch, unintended fast-forward, missing pre-push checks).
Keep /commit local; add push as a separate explicit step or pair with a prevent-commit-main hook so accidental pushes to main are blocked at the tool layer.
Sonnet. Commit-message writing is applied text generation with clear rules, not deep reasoning — Sonnet handles it well and Opus adds cost without commensurate quality lift.
Reserve Opus for genuinely analytical tasks like security review or schema design. For /commit, stick with Sonnet.
It follows Conventional Commits conventions:
- Merges — typically get "Merge branch X into Y" as-is (no rewriting).
- Reverts — get the
revert: <original-subject>format automatically.
For stricter revert messaging, add a rule: "For revert commits, always include the reverted commit's SHA in the body as Reverts: <sha>."
Yes. The command calls git commit, which reads your local git config for signing settings.
If commit.gpgSign or gpg.format is set to ssh, the resulting commit is signed just as if you had run git commit yourself. No changes needed to the command file.
Commit .claude/commands/commit.md to git. That's the whole workflow.
On next pull, every teammate has the command available, using the same style rules and safety patterns. This is exactly why project-scoped slash commands are the standard for team standardization.
Install three commands, in order:
/commitfirst.- /branch second.
- /pr-create third.
Then add /conflict-resolve for peace of mind. That five-piece set covers 80% of daily git in Claude Code.
On top, install prevent-commit-main and secrets-scan-on-write hooks for enforcement. Done — that's the mature git workflow most teams converge on.