| name | commit |
| description | Commit code with parallel subagent analysis, atomic validation, and best practices. Use when the user asks to "commit", "commit changes", "make a commit", "stage and commit", "git commit", or any variation of committing code changes. Also triggers on "/commit", "commit this", "save my changes", "コミット", "コミットして". Covers all commit-related requests including reviewing what to commit, writing commit messages, and validating atomicity. |
Commit Skill
High-quality commits improve code review efficiency, enable effective git bisect,
and create a clear project history. This skill analyzes changes in parallel, validates
commit quality, and produces well-crafted commits.
Phase 1: Parallel Analysis
Launch four subagents simultaneously — they have no dependencies on each other.
1. Change Analysis
Analyze all staged and unstaged changes:
- Run
git diff and git diff --cached to review changes
- Categorize by type: feat, fix, refactor, docs, test, chore, etc.
- Identify primary purpose and scope
- Scan for sensitive information with
rg -i "api.?key|password|secret|token"
Report: change type, scope, files changed, and whether sensitive data was found.
2. Codebase Impact
Assess how changes affect the broader codebase:
- Check for breaking changes or API modifications with
ast-grep
- Find references to changed functions/classes with
rg
- Review test coverage for modified code
- Run
git diff --stat for change scope overview
Report: breaking changes (boolean + details), affected modules, test coverage assessment.
3. Commit Message Draft
Craft a commit message following project conventions:
- Check recent style with
git log --oneline -10
- Look for related issues/PRs with
gh issue list and gh pr list
- Follow Conventional Commits:
type(scope): description
- Subject line rules: max 50 chars, imperative mood, lowercase after type, no trailing period
- Body rules: wrap at 72 chars, explain WHY not just WHAT
Report: subject line, body, footer (Fixes/BREAKING CHANGE), related issues.
4. Atomic Validation
Verify the commit is a single logical unit:
- Count files and lines changed via
git diff --stat
- Check if changes mix unrelated types (e.g., feat + fix + refactor)
- Evaluate whether the change can be described in one sentence
- Each file change should contribute to the same goal
Report: is_atomic (boolean), file/line counts, split recommendations if not atomic.
Phase 2: Synthesis
Review all subagent findings and make decisions:
-
Atomicity — if not atomic, present split recommendations and ask the user
whether to split or proceed as one commit. If splitting, provide specific
git add commands for each part.
-
Sensitive data — if detected, STOP immediately. List files and patterns found.
Do not proceed until the user confirms safety.
-
Breaking changes — if detected, ensure the commit message includes a
BREAKING CHANGE: footer.
-
Consolidate analysis and validate that all changes are appropriate.
Phase 3: Pre-Commit Verification
Run in parallel:
git status — verify repository stategit diff --cached — review what's stagedgit log --oneline -5 — confirm style consistency
Phase 4: Stage and Commit
Proceed directly unless atomicity failed, sensitive data was found, or the user
requested review first.
- Stage relevant changes with
git add (specific files, not -A)
- Create the commit:
type(scope): description
WHY: [Motivation and context]
[Detailed explanation if needed]
[Fixes #xxx | Closes #xxx]
[BREAKING CHANGE: description]
- Verify with
git status
Success Criteria
- Atomic validation passed (or user approved single commit)
- No sensitive information (or user confirmed safe)
- Subject line: max 50 chars, imperative mood, no period
- Body: wrapped at 72 chars, WHY explained
- Conventional Commits format used
- Breaking changes documented if any
- Related issues referenced if applicable
- Commit created and verified
