Slash commands: no more meaningless commits

One of the things I've been using the most since I started with Claude Code is slash commands. And one I think every dev should have is /commit. It cleaned up a habit a lot of devs share, even the experienced ones. /commit makes the bar explicit, and the whole team writes commits the same way now.

I always cared about commit messages. Even devs who care end up with a "fixes" or a generic "update" slipping into the repo on a tired Friday or in the middle of a giant refactor. That's how a repo ends up with a layer of noise nobody can decode three months later.

What is a slash command

Slash commands aren't unique to Claude Code. OpenCode, Codex CLI, Aider, and Continue all let you wire up your own commands somehow. The format and the trigger differ, but the idea is the same: a short keystroke runs a longer prompt you wrote once.

I'll show this with Claude Code, since it's what I use day to day. The setup translates well enough to the others.

In Claude Code, a slash command is just a markdown file. You drop it at ~/.claude/commands/<name>.md (global) or .claude/commands/<name>.md (per project), and now /<name> works as a shortcut. The frontmatter has a description, the body is the prompt the agent reads when you call it.

That's it. No DSL, no SDK, no plugin manifest. Markdown file in, slash command out.

The commit problem

Even with a good agent in the loop, a plain "commit my changes" gets you something passable but not great. The agent picks one type, writes a workable subject line, and lumps unrelated changes into one commit. Better than no agent at all. But it can get better.

What I wanted was something that reads my changes, groups them by domain, writes a decent message following Conventional Commits per group, and skips the files that shouldn't be committed.

/commit

Here's the slash command I built to keep commits clean and consistent:

---
description: Analyze all changes and commit in logical groups.
---

# Commit

## Step 1: Survey changes

Run `bin/commit-survey` to get the file lists and classification.

Read diffs of key files if you need more context on the changes.

## Step 2: Group the changes

Use the `--- classified ---` output as a starting point, then refine into logical commits.

Grouping strategy:
- By domain/feature: e.g., all auth changes together
- By layer: e.g., model tests, controller tests
- By type: e.g., all config changes, all dependency updates

Files in `[skip]` should NOT be committed. If unsure about a file, skip it.

## Step 3: Commit each group

For each group, combine stage + commit in one call:

git add <specific files> && git commit -m "<message>"

Order commits from most independent to most dependent:
- Config/tooling changes first
- Then source code changes
- Then test changes
- Generated files last

Those three steps are the whole engine.

bin/commit-survey

Step 1 calls a script. That's what makes everything else work.

I could ask the agent to run git status, git diff, parse the output and classify the files in its head. It would work most of the time. But then every run burns tokens on the same parsing logic, and the output ends up however Claude felt that day.

A short Ruby script gives you:

One predictable invocation
Fewer tokens spent (no git status output to digest, just the classified result)
Buckets that match how you actually think about your code

The whole thing is ~22 lines:

SKIP_PATTERNS = %w[.env credentials master.key tasks.md notes.txt scratch .claude/]

BUCKETS = {
  "skip"   => ->(path) { SKIP_PATTERNS.any? { |pat| path.include?(pat) } },
  "test"   => ->(path) { path.start_with?("test/") },
  "db"     => ->(path) { path.start_with?("db/") },
  "config" => ->(path) { path.start_with?("config/", "Gemfile", ".rubocop", "Procfile", "Rakefile") },
  "docs"   => ->(path) { path.start_with?("docs/", "README") || path.end_with?(".md") },
  "app"    => ->(_)     { true }
}

paths = `git status --porcelain`.lines(chomp: true).map { |l| l[3..] }
grouped = BUCKETS.keys.to_h { |b| [b, []] }
paths.each { |path| grouped[BUCKETS.find { |_, matcher| matcher.call(path) }.first] << path }

BUCKETS.each_key do |bucket|
  files = grouped[bucket]
  puts "[#{bucket}] #{files.empty? ? "(none)" : files.join(", ")}"
end

skip goes first so secrets and notes never end up staged. The rest is a buffet you tweak per project. A Phoenix app would have lib/, priv/repo/migrations/, assets/. A Next.js app would have pages/, app/, public/, prisma/. Same idea, different paths.

Run it on a dirty repo and you get:

--- unstaged ---
 M config.toml
 M templates/index.html

--- untracked ---
content/blog/_index.md
content/blog/post.md

--- classified ---
[skip]   (none)
[test]   (none)
[db]     (none)
[config] config.toml
[docs]   content/blog/_index.md, content/blog/post.md
[app]    templates/index.html

The agent looks at that and writes maybe three commits: chore(config): bump zola version, feat(templates): add language toggle, feat(blog): bootstrap section. Three focused messages instead of one catch-all.

In action

I type /commit and Claude:

Runs bin/commit-survey and reads the output
Reads diffs on any files where it needs more context
Stages and commits each group with a Conventional Commits message
Skips .env and any secrets quietly

The whole thing takes 30 seconds, and every commit comes out clean and scoped.

Real example from this very blog. Survey output before the run:

[skip]   (none)
[test]   (none)
[db]     (none)
[config] config.toml
[docs]   content/blog/slash-commands-no-more-bad-commits.md, content/blog/slash-commands-no-more-bad-commits.pt-br.md
[app]    sass/_predefined.scss, sass/style.scss

What /commit produced:

feat(blog): add slash commands post in EN and pt-br
chore(config): drop syntax theme, switch to monochrome code blocks
style(sass): apply osaka jade palette and bump body font

Three commits, each with a clear scope.

Make your own

The simplest way to start is to copy this one and tweak it. Drop the file at ~/.claude/commands/commit.md if you want it everywhere, or .claude/commands/commit.md for one project. Adjust the bucket patterns to match your stack. Done.

You can do the same for anything you do often: /changelog, /release, /pr-draft, /deploy. Each one is a markdown file with the steps you would otherwise type into chat every time.

Wrapping up

The setup is small, but the difference shows up in every commit. A custom slash command plus a small helper script is enough to make AI pull its weight on the routine work.

No more "update" commits. Every commit reflects the bar you wrote into the markdown file.

Sources:

GUILHERME YAMAKAWA DE OLIVEIRA