Commit changes with a generated message
Have Claude Code read the diff, check for files that should not go in, and commit with a message that says what changed and why. It does not push.
Task: Commit changes with a generated message · Other tasks
Fill in the details
Optional. The diff shows what changed; only you may know why. Add a ticket number if your team uses them.
Copy your prompt
This site doesn't run Claude or show model output. Results depend on your input and the model you use.
You've edited the prompt, so changes to the fields aren't applied.
Replace what you've entered for this task with the example? This can't be undone.
What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.
When to use this template
- You finished a change and want a commit message that matches what the diff actually contains, without writing it from memory.
- Your working tree mixes several edits, and you want them checked for stray files or grouped into separate commits before anything is recorded.
- Your repository has a commit style, such as a type prefix or a ticket number in the subject, and you want each message to follow it.
When not to use it
- You want the changes pushed and turned into a pull request as well. Use the pull request template, which bounds pushing separately.
- The change is still in progress and you only want a checkpoint for yourself. A quick local commit or a stash is enough, and Claude Code checkpoints already let you rewind its own file edits.
- You are cleaning up history that is already pushed, such as squashing or rewording old commits. That rewrites shared history and needs your own judgment.
Why this structure
- The changes field says what goes in, so Claude commits the files you meant rather than everything in the working tree.
- Step 1 bases the message on the full diff, because a message written from file names describes where the change is, not what it does.
- Step 2 tells Claude to stop and list secrets, local config or unrelated edits it finds instead of committing them. Once a file is committed and pushed, removing it cleanly is much harder.
- The why field and the rule against inventing a reason exist because the diff shows what changed but rarely why. A made-up reason in history misleads the next reader.
- The no-push rule bounds the task to your machine. In auto mode, Claude Code treats a boundary you state in the conversation, such as "do not push", as a reason to block that action.
- Asking for the hash, message and file list at the end gives you evidence to check in seconds, instead of opening git log yourself.
Example input (fictional)
- Changes to commit
only the files in src/reports and its tests
- Why you made the change
Exports used the server timezone, so reports for other regions showed the wrong day.
- Message format
the same style as the recent commits in this repository (check git log)
- Number of commits
make one commit for all of it
Follow-ups to send Claude
- Shorten the subject line to under 50 characters and move the details into the body.
- Split the last commit into two: one for the timezone fix and one for the new tests. Show me the plan before you change anything.
- Now push this branch and open a pull request with a description based on the commit messages. Ask me before pushing.
Common mistakes
- Asking for a commit with no scope while unrelated edits sit in the working tree. Name the files or folders, or ask Claude to propose a grouping first.
- Accepting a message that only repeats the diff, such as "update report.js". Give the reason in the why field so the body explains the change.
- Allowing
git commitwithout review and assuming nothing else runs. If you add it to your permission allowlist, still read the summary Claude shows after each commit.
Related templates
- Draft release notes from git history: Have Claude Code compare two git tags or branches and draft release notes grouped into breaking changes, features and improvements for your readers.
- Resolve merge conflicts and explain the result: Tell Claude Code what each branch was meant to do; it resolves the conflicts, runs your checks and explains what it kept from each side.
- Open a pull request from a ticket: Point Claude Code at a ticket in your connected tracker; it reads it, implements the change on a new branch, runs the tests and prepares the pull request.
Sources
- Claude Code docs: Prompt library (Anthropic documentation)
- Claude Code best practices: Explore first, then plan, then code (Anthropic documentation)
- Claude Code best practices: Configure permissions (Anthropic documentation)
- Claude Code best practices: Rewind with checkpoints (Anthropic documentation)
- Claude Code docs: Boundaries you state in conversation (Anthropic documentation)