Create Commits

You are analyzing the working tree to create logical, atomic git commits with appropriate commit messages.

Configuration

Check for .claude/git.local.md in the project root for user preferences:

---
commit_style: conventional  # conventional | repo-style | custom
custom_format: ""           # Custom format template if style is "custom"
auto_stage: false           # Whether to auto-stage unstaged changes
split_commits: true         # Whether to split changes into multiple logical commits
---

If no config exists, use the defaults above.

Workflow

1. Detect Commit Message Style

Determine the commit message format in this priority order:

a) User-specified — if /create-commits --style conventional or config file specifies a style, use it.

b) Repo style — analyze the last 5 commits to detect the pattern:

git log --oneline -5

Look for patterns:

• Conventional Commits: feat:, fix:, chore:, docs:, etc. → use conventional
• Angular: feat(scope): → use conventional with scope
• Imperative: "Add feature", "Fix bug" → use imperative capitalized
• Lowercase imperative: "add feature", "fix bug" → use imperative lowercase
• If no clear pattern, fall back to Conventional Commits

Report the detected style to the user.

c) Fallback — Conventional Commits per https://www.conventionalcommits.org/en/v1.0.0/

2. Analyze Changes

Run these commands to understand what needs committing:

git status
git diff --stat
git diff --cached --stat

Read the actual diffs to understand the changes:

git diff
git diff --cached

3. Plan Commits

Group related changes into logical, atomic commits. Each commit should:

• Address a single concern (one feature, one fix, one refactor)
• Be self-contained and not break the build
• Have a clear, descriptive message following the detected style

When to split into multiple commits:

• Changes span unrelated features or bug fixes
• A refactor is mixed with a feature addition
• Test changes are separate from implementation
• Documentation changes are separate from code changes

When to keep as a single commit:

• All changes are part of one coherent task
• Changes are small and tightly related
• Splitting would create commits that don't stand alone

4. Review (only with --review flag)

If --review was passed, show the commit plan and wait for user approval before executing:

## Commit Plan

Detected style: Conventional Commits (from repo history)

### Commit 1
Files: src/auth.ts, src/auth.test.ts
Message: feat: add JWT token refresh on expiry

### Commit 2
Files: README.md
Message: docs: document JWT refresh behavior

Proceed with these commits?

If not approved, adjust based on user feedback. If --review was NOT passed, skip this step and execute directly.

5. Execute Commits

For each planned commit:

1. Stage the specific files:

   git add <file1> <file2> ...
   

2. Create the commit (use HEREDOC for the message):

   git commit -m "$(cat <<'EOF'
   <commit message>
   EOF
   )"
   

3. Verify the commit succeeded with git status

Important:

• Stage specific files, never git add -A (may include sensitive files)
• If a pre-commit hook fails, fix the issue, re-stage, and create a NEW commit (never --amend)
• Never use --no-verify

6. Report

## Commits Created

1. abc1234 feat: add JWT token refresh on expiry (3 files)
2. def5678 docs: document JWT refresh behavior (1 file)

Total: 2 commits

Arguments

Edge Cases

• No changes: Report "Nothing to commit" and exit
• Only staged changes: Commit only what's staged, mention unstaged files
• Only unstaged changes: Ask user if they want to stage and commit
• Merge conflicts: Report conflicts and suggest resolution before committing