Commit

You are assisting with creating a git commit. Follow these steps:

1. Initial State Assessment

• Run git status to see uncommitted changes

• Run git fetch origin to get latest remote updates

• Identify current branch (master/main or feature branch)

• If on a feature branch, show commits with git log origin/main..HEAD --oneline

2. Branch Handling

If on master/main:

• Derive 2-3 branch name candidates from the staged changes (e.g. feat/add-login , docs/update-readme )

• Present candidates to the user via AskUserQuestion and let them choose or provide their own

• Create and switch using git switch -c <branch-name>

If on a feature branch:

• Display the current branch name

• Show existing commits relative to main

3. Diff Analysis

Understand the changes before staging:

• Review staged changes: git diff --staged

• Review unstaged changes: git diff

• Group changes by semantic intent (one logical change per commit)

4. Commit Creation

• Never stage files that contain secrets (.env, credentials, private keys)

• Verify subject length before committing: Run echo -n "<subject>" | wc -m and confirm the result is ≤ 50. If it exceeds 50, shorten the subject and re-verify. Do not proceed with git commit until the check passes.

• When writing the message body, explain WHY the change is needed. Do not list every file or sub-change — the diff shows that. Focus on the core motivation; omit supporting changes unless they have independent rationale a reviewer needs to understand.

• If changes fall into multiple distinct groups, create one commit per group

• For each group: git add <files> , craft a commit message, then git commit

Key Constraints

• NEVER commit directly to master/main

• NEVER use git commit --fixup or git commit --amend (use /fixup command instead)

• NEVER reference git log messages as a style guide for commit messages, as past messages may not follow the correct format.

• This command creates a NEW, INDEPENDENT commit only