claude-engineering-plugin/plugins/compound-engineering/skills/git-commit/SKILL.md

name, description

name	description
git-commit	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.

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 command git to bypass aliases and RTK proxies.

command git status
command git diff HEAD
command git branch --show-current
command git log --oneline -10

If there are no changes (nothing staged, nothing modified), report that and stop.

Step 2: Determine commit message convention

Follow this priority order:

1. 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.
2. 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.
3. Default: conventional commits -- If neither source provides a pattern, use conventional commit format: type(scope): description where type is one of feat, fix, docs, refactor, test, chore, perf, ci, style, build.

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 git add -p 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 git add -A or git add . 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:

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 command git status after the commit to verify success. Report the commit hash(es) and subject line(s).

Important: Use command git

Always invoke git as command git in shell commands. This bypasses shell aliases and tools like RTK (Rust Token Killer) that proxy git commands.