@paperclip-skills/git-commit-review

Guides agents through reviewing staged git changes and producing well-structured conventional commit messages. Ensures diffs are clean, nothing is accidentally staged, and commit messages are informative.

When to Use

Activate when:

User asks to review staged changes before committing
User asks for help writing a commit message
User says "commit", "review my changes", "what did I change", or "prepare a commit"
Agent has completed a coding task and needs to commit the result

Steps

1 — Gather Context

Run these commands to understand the current state:

git status                          # overview of staged, unstaged, untracked
git diff --cached --stat            # summary of staged changes
git diff --cached                   # full staged diff
git log --oneline -5                # recent commit style reference

2 — Review the Diff

Check the staged diff for:

| Check | Action | |-------|--------| | Secrets or credentials | Flag immediately — .env, API keys, tokens, private keys | | Debug artifacts | console.log, debugger, TODO, FIXME left behind | | Unrelated changes | Mixed concerns — suggest splitting into separate commits | | Large binary files | Warn if binaries are staged (images, compiled assets) | | Empty files | Files with no content that may be accidental |

If issues are found, report them to the user before proceeding.

3 — Classify the Change

Determine the change type from the diff:

| Type | When | |------|------| | feat | New feature or capability | | fix | Bug fix | | refactor | Code restructuring without behavior change | | docs | Documentation only | | test | Adding or updating tests | | chore | Build, CI, dependencies, config | | style | Formatting, whitespace, linting | | perf | Performance improvement |

4 — Write the Commit Message

Follow conventional commit format:

<type>(<scope>): <short summary>

<body — optional, explains WHY not WHAT>

Rules:

Subject line: imperative mood, max 72 chars, no period
Scope: the module, file, or feature area affected
Body: wrap at 72 chars, separated by blank line, explain motivation
Focus on WHY the change was made, not WHAT changed (the diff shows that)

Examples:

feat(auth): add SIWE wallet challenge flow

Implements nonce-based challenge-response for wallet ownership
verification before API key issuance.

fix(api): prevent race condition in nonce redemption

Use atomic compare-and-swap on usedAt field to prevent
concurrent redemption of the same challenge nonce.

5 — Stage and Commit

git add <specific-files>            # prefer explicit files over `git add .`
git commit -m "<message>"

Do not:

Use git add . or git add -A without reviewing untracked files
Use --no-verify to skip pre-commit hooks
Amend commits unless explicitly asked
Push unless explicitly asked

Reference

Conventional Commit Types

feat · fix · refactor · docs · test · chore · style · perf · ci · build · revert

Commit Message Anti-Patterns

"fix stuff" — too vague
"update code" — says nothing
"WIP" — not ready to commit
"addressing PR feedback" — use the actual change description
Starting with "This commit..." — redundant

git-commit-review