Commit Multi

Break up the pending changes into small, logical commits and commit them using well-structured commit messages.

nozzlegear 7 updated 24d ago
Claude CodeGeneric
View source ↗
---
title: 'Git Commit Multiple Task'
read_only: true
type: 'command'
---

Break up the pending changes into small, logical commits and commit them using well-structured commit messages.

## Description

This command analyzes pending git changes and breaks them up into small, logical commits. Each commit is created with a clear, concise commit message. It reviews the changes, categorizes the nature and scope, and then commits them without asking for confirmation.

For every commit:
- Append the nature and scope to the commit in git trailers, e.g. `type: fix` or `type: refactor`.
- Do NOT prefix commit messages with the conventional commits standard.
- Do NOT list the files that were changed in commit messages or bodies.
- Do NOT add Claude co-authorship footer to commit messages or bodies.

## Usage
`commit-multi`

## Steps
1. Run `git status` to see pending git changes
2. Review staged changes with `git diff --cached` if needed
   - The user may intend for staged changes to be committed first in their own commit.
3. Analyze the nature of changes:
   - Feature additions (feature)
   - Bug fixes (fix)
   - Documentation (docs)
   - Style changes (style)
   - Refactoring (refactor)
   - Tests (test)
   - Chores (chore)
4. Decide how best to group the pending changes:
   - By feature
   - By individual bug fixes
   - By chore
   - By a file's purpose
5. Stage the files needed for your commit.
   - Partial file staging (e.g. only stage lines 5 to 12) is encouraged where it makes sense.
6. Write a commit message with:
   - Clear, imperative mood description
   - Body with "why" and "what" if needed
   - Footer with references if applicable
   - Nature and scope in the trailers (`type: fix` or `scope: feat`)
7. Go back to Step 1 and repeat until no more relevant files are left to commit.
   - Depending on your conversation history, the user may not intend for you to commit certain files at all, e.g. `secrets.yaml` or `.env`.

## Example commit messages
### Example 1: Simple feature commit

Add password reset functionality

Implemented the Forgot Password flow with a 24h expiry for the Password Reset tokens. Added the Email Notification service.

type: feature scope: auth


### Example 2: Bug fix commit

Resolve null pointer in user validation

Validation was failing when optional fields were undefined. Added null checks before accessing nested properties.

Fixes #123

type: fix scope: auth


## Notes
- Keep subject line under 90 characters
- Use present tense ("add" not "added")
- Reference issues/PRs when relevant
- Do NOT list the files that were changed in commit messages or bodies.
- Do NOT add Claude co-authorship footer to commit messages or bodies.
- Always use American English when writing a commit message.

Maintain Commit Multi?

Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.

[Commit Multi on getagentictools](https://getagentictools.com/loops/nozzlegear-commit-multi?ref=badge)