Ask Claude to Write Commit Messages by Reading Your Staged Diff
Writing good commit messages takes effort. Claude reads your actual changes and writes one that explains what happened and why — in whatever format your team uses.
"Read the staged diff and write a commit message"
Claude runs git diff --staged, reads every changed file, understands the intent behind the changes, and writes a message that captures the why — not just a list of files touched.
Instead of writing this yourself:
Updated user controller and added migration
Claude produces:
feat: add email verification requirement to user registration
Adds a verified_at column to users and requires email verification
before allowing access to protected routes. Existing users are
grandfathered in with verified_at set to their created_at date.
You can specify the format you want:
# Conventional commits
"Write a conventional commit message for the staged changes"
# With scope
"Write a commit message with scope, following our team convention"
# Multi-paragraph for complex changes
"Write a detailed commit message with a summary line and body explaining the tradeoffs"
# Simple and short
"Write a one-line commit message for these changes"
Claude adapts to your project's style. If your recent commits use a specific format, mention it:
"Write a commit message matching the style of our last 5 commits"
This works especially well as a custom slash command:
<!-- .claude/commands/commit.md -->
Read the staged diff with git diff --staged. Write a conventional
commit message. Stage any unstaged related files if appropriate.
Create the commit.
Then just type /commit after staging your changes.
Good commit messages are a gift to your future self — let Claude write them while the changes are fresh.
via Claude Code
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.