From git-commit
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.
npx claudepluginhub xobotyi/cc-foundry --plugin git-commitThis skill is limited to using the following tools:
<prerequisite>
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Skill(git-commit:commit-message)
Do not proceed without loading the skill.
git branch --show-currentgit status --shortgit diff --cached --statgit diff --statgit log --oneline -5<git-commit-config>
<validator-args>
<flag name="require-trailers" value="Task"/>
</validator-args>
<extra-instructions>
Project-specific commit guidance goes here.
</extra-instructions>
</git-commit-config>
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.
If uncertain, re-read staged changes with git diff --cached to re-anchor.
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:
Each independent change becomes its own commit.
For each identified unit, classify and order:
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.
After returning from fixes: Re-read <pipeline-awareness> above. Verify you're resuming at step 4, not starting
over or skipping steps.
Before each commit, verify:
git diff --cached # Review exactly what will be committed
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.
node ${CLAUDE_PLUGIN_ROOT}/scripts/validate-commit-message.js [validator-args] --msg "<commit-message>"
<validator-args> exists in project config, include those flagsBefore executing git commit, display the full message as a blockquote.
Then commit:
git commit -m "<validated-message>"
After committing, run each as a separate Bash call:
git log -1 --stat
git status
When a commit breaks backward compatibility:
1. **Prefer incremental migration:** - Add new code without removing old - Migrate callers from old to new - Remove old code when no callers remainBREAKING: prefixAfter completing all commits, show: