Create a git commit with a clear, value-communicating message. Use when the user says "commit", "commit this", "save my changes", "create a commit", or wants to commit staged or unstaged work. Produces well-structured commit messages that follow repo conventions when they exist, and defaults to conventional commit format otherwise.
Create a single, well-crafted git commit from the current working tree changes.
Run these commands to understand the current state.
git status
git diff HEAD
git branch --show-current
git log --oneline -10
git rev-parse --abbrev-ref origin/HEAD
The last command returns the remote default branch (e.g., origin/main). Strip the origin/ prefix to get the branch name. If the command fails or returns a bare HEAD, try:
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
If both fail, fall back to main.
If the git status result from this step shows a clean working tree (no staged, modified, or untracked files), report that there is nothing to commit and stop.
Run git branch --show-current. If it returns an empty result, the repository is in detached HEAD state. Explain that a branch is required before committing if the user wants this work attached to a branch. Ask whether to create a feature branch now. Use the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). If no question tool is available, present the options and wait for the user's reply before proceeding.
git checkout -b <branch-name>, then run git branch --show-current again and use that result as the current branch name for the rest of the workflow.Follow this priority order:
type(scope): description where type is one of feat, fix, docs, refactor, test, chore, perf, ci, style, build.Before staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.
Keep this lightweight:
git add -p or try to split hunks within a file.Run git branch --show-current. If it returns main, master, or the resolved default branch from Step 1, warn the user and ask whether to continue committing here or create a feature branch first. Use the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). If no question tool is available, present the options and wait for the user's reply before proceeding. If the user chooses to create a branch, derive the name from the change content, create it with git checkout -b <branch-name>, then run git branch --show-current again and use that result as the current branch name for the rest of the workflow.
Stage the relevant files. Prefer staging specific files by name over git add -A or git add . to avoid accidentally including sensitive files (.env, credentials) or unrelated changes.
Write the commit message:
Use a heredoc to preserve formatting:
git commit -m "$(cat <<'EOF'
type(scope): subject line here
Optional body explaining why this change was made,
not just what changed.
EOF
)"
Run git status after the commit to verify success. Report the commit hash(es) and subject line(s).