Git commit workflow pipeline: atomic unit identification, commit ordering, quality gates, message validation, and post-commit verification. Invoke whenever task involves any interaction with git commits — committing changes, staging work, splitting diffs into atomic units, or preparing work for version control.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Git commit workflow pipeline: atomic unit identification, commit ordering, quality gates, message validation, and post-commit verification. Invoke whenever task involves any interaction with git commits — committing changes, staging work, splitting diffs into atomic units, or preparing work for version control.
Before starting the pipeline, check project CLAUDE.md for <git-commit-config>:
<validator-args> — Pass all defined flags directly to the validator. Each <flag name="X" value="Y"/> becomes
--X "Y" in the command.
<extra-instructions> — Highest priority guidance for this commit process. Follow these instructions throughout
the pipeline. They override defaults.
Commit Pipeline
**One git command per Bash call.** Every Bash invocation must start with
`git` or `node`. Never chain commands with `&&`, `||`, or `;`. Never pipe
input to git commands.
**Context drift prevention.** Steps like Quality Gate may require fixing
code, running tests, or debugging — work that can span many turns. Before
executing any git command, verify you haven't lost the pipeline:
Am I in the commit pipeline? (If not, return to step 1)
Which step am I on?
Were prior steps completed?
If uncertain, re-read staged changes with git diff --cached to re-anchor.
1. Identify Atomic Units
Review the diff and identify separate logical changes:
git diff HEAD # All changes
git diff --cached # Staged only
**One logical change per commit.** Look for boundaries:
Different files serving different purposes
Formatting/style changes mixed with logic changes
Refactoring mixed with new behavior
Unrelated bug fixes bundled together
Each independent change becomes its own commit.
2. Plan Commit Order
For each identified unit, classify and order:
Style (1st) — Formatting, whitespace, naming
Refactor (2nd) — Code restructuring, no behavior change
Fix (3rd) — Bug corrections
Feature (4th) — New functionality
Docs (any) — Documentation only
Test (any) — Adding or fixing tests
Chore (any) — Build, tooling, dependencies
Commit style/refactor first — keeps behavior-changing commits clean.
Review context: Were lint/test/build commands run earlier in this session for the changed files? If yes and they
passed, proceed.
If not verified: Run appropriate quality checks for the project. Use your knowledge of the codebase to determine
what checks apply. Scope to changed files when possible for faster feedback.
On failure: Fix issues before proceeding. Do not commit broken code.
On success: Continue to self-review.
Gate results stay out of the commit message. Test pass counts, lint/typecheck/build status, and "all checks pass"
are facts about this session, not the change. They belong nowhere in the subject, body, or trailers — keep them in the
terminal.
After returning from fixes: Re-read <pipeline-awareness> above. Verify you're resuming at step 4, not starting
over or skipping steps.
4. Self-Review Before Commit
Before each commit, verify:
Diff contains only intended changes (no debug code, temp files)
Changes match the commit message you're about to write
No unrelated changes bundled together
Sensitive data excluded (.env, credentials, secrets)
Message has no filler tics ("this commit", "I", "we", "now"), no promotional adjectives, no scope-restating
Message has no session artifacts (test counts, lint/CI/quality-gate status, "all checks pass")
git diff --cached # Review exactly what will be committed
5. Stage Files
For each logical unit:
git add <files>
Do not use git add -p or pipe input to interactive commands — these break tool permission matching. Stage by explicit
file path. If a file contains mixed changes, split it in a prior refactoring commit or accept the broader staging.
6. Validate Message
**Before committing, validate the message against conventions:**
