Git Commit
Create a single, well-crafted git commit from the current working tree changes.
Workflow
Step 1: Gather context
Run these commands to understand the current state. Use
to bypass aliases and RTK proxies.
bash
command git status
command git diff HEAD
command git branch --show-current
command git log --oneline -10
command git rev-parse --abbrev-ref origin/HEAD
The last command returns the remote default branch (e.g.,
). Strip the
prefix to get the branch name. If the command fails or returns a bare
, try:
bash
command gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
If both fail, fall back to
.
If there are no changes (nothing staged, nothing modified), report that and stop.
If the current branch matches
,
, or the resolved default branch name, warn the user and ask whether to continue committing here or create a feature branch first. Use the platform's blocking question tool (
in Claude Code,
in Codex,
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 and switch to it before continuing.
Step 2: Determine commit message convention
Follow this priority order:
- Repo conventions already in context -- If project instructions (AGENTS.md, CLAUDE.md, or similar) are already loaded and specify commit message conventions, follow those. Do not re-read these files; they are loaded at session start.
- Recent commit history -- If no explicit convention is documented, examine the 10 most recent commits from Step 1. If a clear pattern emerges (e.g., conventional commits, ticket prefixes, emoji prefixes), match that pattern.
- Default: conventional commits -- If neither source provides a pattern, use conventional commit format: where type is one of , , , , , , , , , .
Step 3: Consider logical commits
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:
- Group at the file level only -- do not use or try to split hunks within a file.
- If the separation is obvious (different features, unrelated fixes), split. If it's ambiguous, one commit is fine.
- Two or three logical commits is the sweet spot. Do not over-slice into many tiny commits.
Step 4: Stage and commit
Stage the relevant files. Prefer staging specific files by name over
or
to avoid accidentally including sensitive files (.env, credentials) or unrelated changes.
Write the commit message:
- Subject line: Concise, imperative mood, focused on why not what. Follow the convention determined in Step 2.
- Body (when needed): Add a body separated by a blank line for non-trivial changes. Explain motivation, trade-offs, or anything a future reader would need. Omit the body for obvious single-purpose changes.
Use a heredoc to preserve formatting:
bash
command git commit -m "$(cat <<'EOF'
type(scope): subject line here
Optional body explaining why this change was made,
not just what changed.
EOF
)"
Step 5: Confirm
Run
after the commit to verify success. Report the commit hash(es) and subject line(s).
Important: Use
Always invoke git as
in shell commands. This bypasses shell aliases and tools like RTK (Rust Token Killer) that proxy git commands.