Automating Git Commits with Claude Code Slash Commands

Published: at 06:41 AM

Slash commands in Claude Code are custom automations you can trigger with a / prefix. They’re like macros that can run complex sequences of commands, analyze code, and perform repetitive tasks. You write them as markdown files with YAML frontmatter that specify what tools Claude can use and what task to perform. Have a prompt you are running over and over again? Save it in a slash command.

I asked ChatGPT for git commit best practices and it generated a complete Claude Code slash command.

TL;DR Recommended Spec if you want a single go-to spec that works well for open source and teams::

  1. Follow Conventional Commits for structure.
  2. Follow Chris Beams’ 7 rules for style.

Now I can type /commit and get properly formatted commit messages automatically.

The Command File

---
description: Generate a Conventional Commits–style message from the current git diff using our team spec, then commit and push
argument-hint: "[optional summary or scope]"
model: claude-3-5-sonnet-20241022
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git branch:*), Bash(git log:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*)
---

# Context (auto-collected)

- Current branch: !`git branch --show-current`
- Recent commits (last 5): !`git log --oneline -5`
- Git status: !`git status --porcelain=v1`
- Diff vs HEAD (staged & unstaged): !`git diff HEAD`

# Task

1. Using the context above, generate a commit message following the **Commit Message Spec** below
2. Stage all changes with `git add -A`
3. Commit with the generated message
4. Push to the current branch

If `$ARGUMENTS` are provided, treat them as hints for `scope` and/or the short summary.

Prefer one clear commit over many. If multiple logical changes are detected, warn the user but proceed with the best single commit message possible.

---

## Commit Message Spec (enforced)

### 1) Format

    <type>(<scope>)!?: <Imperative summary, ≤50 chars>

    [Body: what & why, wrapped at 72 chars]

    [Footer(s): metadata like issues, BREAKING CHANGE]

- **type** (one): feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
- **scope** (optional, kebab-case): e.g. auth, api, ui, deps, infra
- **!** (optional): indicates a breaking change in the subject line

### 2) Subject (Top Line)

- Imperative mood ("Add", not "Added"/"Adds")
- ≤50 chars, capitalized, no trailing period
- One blank line after the subject

### 3) Body (Explain What & Why)

- Wrap at 72 chars
- Focus on **what changed** and **why** (not the how)
- Mention user impact, trade-offs, and relevant context
- Include migration notes if behavior changes

**Body checklist**

- Motivation / context
- What changed at a high level
- Impact / risks / rollback notes

### 4) Footers (Metadata)

- Closes #123 / Fixes #123 / Refs #123
- BREAKING CHANGE: <details + migration>
- Co-authored-by: Name <email>
- Signed-off-by: Name <email> (if DCO)

**Breaking changes**

- Use **!** in the subject **or** a BREAKING CHANGE: footer (or both)
- State what breaks and how to migrate

### 5) SemVer Mapping

- **feat** → **minor**
- **fix** → **patch**
- **feat!** or **BREAKING CHANGE** → **major**

### 6) Examples

Good:

    feat(auth): add password reset endpoint

    Adds POST /reset-password to allow email-based token resets.
    Sends time-limited tokens and invalidates on use.

    Closes #482

---

    fix(ui): prevent sidebar overflow on Safari 17

    Use flex-basis and min-width to avoid text clipping on narrow
    viewports.

    Refs #519

---

    docs(readme): add installation instructions for pnpm

---

    feat(api)!: require auth token for all POST routes

    All POST routes now validate JWTs. Anonymous writes removed.

    BREAKING CHANGE: Clients must include Authorization: Bearer <jwt>.

Revert:

    revert: feat(auth): add password reset endpoint

    Reverts commit abc1234 due to regression in SSO flow.

---

## Heuristics the assistant should apply

- Infer **type** from changes (tests → test, perf-sensitive code → perf, only deps → build or chore(deps))
- Prefer a concrete **scope** when files cluster clearly (e.g., directory or package name)
- If diff shows widespread API changes, consider ! and describe migration in the body/footer
- Keep subject ≤50 chars; if longer, tighten language without losing meaning
- If an issue key like #123 appears in diff, include a footer reference

---

## Execution Steps

After generating the commit message:

1. Execute: git add -A
2. Execute: git commit -m "<generated message>"
3. Execute: git push origin <current-branch>
4. Show the commit message that was used and report success/failure of each step

---

## Usage

- **Project command**: save this file as .claude/commands/commit.md in your repo.
- Run inside Claude Code chat: /commit [optional scope or summary hint]
- **Personal command**: alternatively save as ~/.claude/commands/commit.md to use across projects.

How to Use It

Save this file as:

The filename becomes the command name. Call it with /commit in Claude Code. You could rename it to /git for something shorter.

Claude Code Co-Author Attribution

By default, Claude Code adds itself as a co-author in commit messages:

Claude Code co-author in git commit

To disable this, add to your settings.json:

{
  "includeCoAuthoredBy": false
}

See Claude Code settings documentation for more configuration options.

The Token Cost

Yes, this burns through tokens. A typical commit with this command uses around 300-600 tokens just to avoid writing a one-line commit message. Is it worth it? Woo not sure. Do I use it anyway? Yeah, but I feel guilty if I think about it too much.

Probably all overkill and either go back to doing git manually, or use a smaller command file.

This will probably come in handy the next time I need to scrape as I tend to run the same prompts over and over again with a few different arguments passed in.

Update: Ok, turns out descriptive git commands might be helpful for the AI to find old code that was useful, either as a reference, or to restore.