From git-commit-assistant
Assesses if current git changes form an atomic commit or should be split into multiple focused commits, providing detailed analysis, criteria, and splitting suggestions.
How this command is triggered — by the user, by Claude, or both
Slash command
/git-commit-assistant:assess-atomicitycommit-analysis/The summary Claude sees in its command listing — used to decide when to auto-load this command
# Operation: Assess Atomicity Determine if changes form an atomic commit (single logical change) or should be split into multiple focused commits. ## Parameters from $ARGUMENTS No parameters required. Analyzes all current changes. ## Workflow ### Step 1: Gather Change Data ### Step 2: Run Atomicity Analysis Execute atomicity checker script: The script analyzes: - Number of files changed - Types of changes (feat, fix, docs, etc.) - Scopes affected - Interdependencies - Logical cohesion ### Step 3: Atomicity Criteria **Atomic Commit** (single commit appropriate): - All changes s...
Determine if changes form an atomic commit (single logical change) or should be split into multiple focused commits.
No parameters required. Analyzes all current changes.
git status --short
git diff HEAD --stat
git diff HEAD
Execute atomicity checker script:
git diff HEAD | .scripts/atomicity-checker.py
The script analyzes:
Atomic Commit (single commit appropriate):
Non-Atomic (should split):
If non-atomic, suggest how to split:
By Type:
Split into commits by change type:
1. feat(auth): OAuth implementation (5 files)
2. test(auth): OAuth tests (2 files)
3. docs: authentication guide (1 file)
By Scope:
Split into commits by module:
1. feat(auth): authentication system (6 files)
2. feat(api): user API endpoints (4 files)
3. feat(ui): login components (3 files)
By Feature:
Split into commits by logical unit:
1. feat(payments): Stripe integration (8 files)
2. feat(payments): PayPal integration (6 files)
3. test(payments): payment tests (4 files)
ATOMICITY ASSESSMENT
═══════════════════════════════════════════════
STATUS: <ATOMIC | SHOULD SPLIT>
ANALYSIS:
───────────────────────────────────────────────
Files Changed: X
Lines Changed: +XXX -XXX
Type Diversity: <Single | Multiple>
Scope Diversity: <Single | Multiple>
Logical Cohesion: <High | Medium | Low>
ATOMICITY CHECKS:
───────────────────────────────────────────────
✓ Single logical purpose
✓ Related files only
✓ Same change type
✓ Same scope
✓ Interdependent changes
✓ Complete unit
✓ Can be reverted independently
OR
✗ Multiple purposes detected
✗ Unrelated files mixed
✗ Multiple change types
✗ Multiple scopes
✗ Independent changes
✗ Incomplete without splits
REASONING:
───────────────────────────────────────────────
<detailed explanation>
If ATOMIC:
All changes implement [specific feature/fix].
Files work together and depend on each other.
Single commit tells a clear, focused story.
If SHOULD SPLIT:
Changes address multiple concerns:
1. <concern 1>
2. <concern 2>
3. <concern 3>
Each concern should be a separate commit.
SPLITTING RECOMMENDATIONS:
───────────────────────────────────────────────
<if should split>
Recommended Commits:
Commit 1: <type>(<scope>): <description>
Files: X files
Purpose: <specific purpose>
Files:
- file1.js
- file2.js
Lines: +XX -YY
Commit 2: <type>(<scope>): <description>
Files: X files
Purpose: <specific purpose>
Files:
- file3.js
- file4.js
Lines: +XX -YY
BENEFITS OF SPLITTING:
───────────────────────────────────────────────
<if should split>
- Better code review (focused changes)
- Easier to revert individual features
- Clearer git history
- Better bisecting for bugs
- Easier cherry-picking
RECOMMENDATION:
───────────────────────────────────────────────
<specific actionable recommendation>
═══════════════════════════════════════════════
Question: Can you describe ALL changes in one sentence?
Atomic Examples:
Non-Atomic Examples:
Atomic:
Non-Atomic:
Atomic:
Non-Atomic:
Test: If reverted, does it break unrelated functionality?
Atomic:
Non-Atomic:
Atomic:
Non-Atomic:
Generally Atomic:
Usually Non-Atomic:
Exceptions:
Atomic? Usually YES
Example:
feat(auth): implement OAuth authentication
- 5 implementation files
- 2 test files
→ ATOMIC (7 files, same feature)
Atomic? DEPENDS
Example:
feat(auth): add OAuth support
- 5 auth files
- 1 auth documentation file
→ ATOMIC (documents the feature)
vs.
feat(auth): add OAuth support
- 5 auth files
- README general update
→ NON-ATOMIC (split docs)
Atomic? NO
Example:
Changes:
- Refactor utils (3 files)
- Add new payment feature (5 files)
→ NON-ATOMIC
Split:
1. refactor(utils): simplify utility functions
2. feat(payments): add Stripe integration
Atomic? DEPENDS
Example:
fix(auth): resolve three auth-related bugs
- All in auth module
- All are fixes
- Related to each other
→ ATOMIC
vs.
- Fix auth bug
- Fix API bug
- Fix UI bug
→ NON-ATOMIC (different scopes)
Return:
No changes:
NO CHANGES TO ASSESS
Working tree is clean.
Single file change:
ATOMIC (Single File)
One file changed: <filename>
Automatically atomic.
The commit-assistant agent uses this operation to:
# Agent checks atomicity before committing
# User: "commit my changes"
# Agent: Invokes assess-atomicity
# Operation: Returns "SHOULD SPLIT"
# Agent: "Your changes should be split. Run /commit-review"
npx claudepluginhub dhofheinz/open-plugins --plugin git-commit-assistant/atomic-commitAnalyzes git changes to detect mixed concerns and helps create clean, atomic commits with suggestions.
/commit-chunksAnalyzes local git changes and proposes splitting into multiple logical commits with messages and files. Commits all after user confirmation using git CLI.
/semantic-commitAnalyzes large git changes, groups into logical units with semantic messages, and creates atomic commits after approval. Supports --dry-run, --lang, --max-commits options.
/organizeOrganizes pending staged and unstaged git changes into multiple atomic commits by grouping into logical units, staging selectively, and using git-ai-commit.