brandtam Commit
Generate a commit message for the current changes, then optionally execute the commit with user approval.
Workflow
Step 1 — Gather fresh state
Run all three in parallel — never reuse results from earlier in the conversation:
git status
git diff HEAD
git diff --cached
Determine: are there staged files? Unstaged changes? Untracked files?
If there are no changes at all (nothing staged, unstaged, or untracked), tell the user there's nothing to commit and stop.
Step 2 — Staging decision
If there are already staged files AND unstaged/untracked changes, ask the user:
- Staged files only — write commit for what's already staged
- Stage all changes — run
git add -A, then write commit for everything
If everything is already staged, skip this question. If nothing is staged, ask:
- Stage all changes — run
git add -A - Select files — let the user tell you which files to stage
After staging is resolved, re-run git diff --cached to see exactly what will be committed.
Step 3 — Check for commit template
Check for a repo-level commit template:
git config --get commit.template
Also check for .gitmessagetemplate or .git-commit-template in the repo root.
- If a template exists, read it and follow its format for the commit message.
- If no template exists, use the default format below.
Step 4 — Write the commit message
Default format
- A single summary line (imperative mood, under 70 characters)
- A blank line
- A bulleted list of what the code does NOW
Message rules
Describe the result, not the process. No "Fix bug that was introduced when..." or "Refactor after code review found..."
Each bullet: a discrete capability, integration, or architectural change as it exists in the final code
Imperative mood ("Add X", "Extract Y", "Update Z")
If
CONTEXT.mdexists in the repo, use its domain terms. If absent, proceed silently.Group related changes into single bullets rather than listing every file
Omit intermediate steps, failed approaches, iterative fixes — only the current state
Never describe corrections to things that were never committed. If a value was wrong in the working tree but never in git history, describe the current (correct) state.
8–15 bullets for large changes, fewer for small ones
Never append Co-Authored-By, Signed-off-by, or any trailer lines to the commit message
Display the full commit message to the user in a code block.
Step 5 — User approval
After displaying the message, ask the user:
- Commit now — execute
git commitwith the displayed message - Make changes — user provides feedback, you revise the message, then ask again
- End now — exit without committing
NEVER commit without the user choosing "Commit now."
When committing, use a HEREDOC to pass the message:
git commit -m "$(cat <<'EOF'
<message here>
EOF
)"
After a successful commit, show the user the commit hash and summary.