atomic-commits
This skill should be used for guidance on commit size, scope, and creating reviewable commits, splitting large changes, commit hygiene
When & Why to Use This Skill
The Atomic Commits skill optimizes your software development workflow by providing expert guidance on creating small, logical, and reviewable Git commits. It focuses on improving commit hygiene, splitting large pull requests into manageable units, and ensuring each change is documented with clear 'why' reasoning. By following these principles, developers can significantly streamline the code review process, enhance repository maintainability, and improve overall team collaboration.
Use Cases
- Scenario 1: Splitting a complex feature implementation into smaller, logical commits to facilitate faster and more effective peer code reviews.
- Scenario 2: Maintaining high commit hygiene by strictly separating code refactoring from new functional changes within the version history.
- Scenario 3: Implementing task-based commit strategies that map individual development plan items to specific commits for better project traceability.
- Scenario 4: Enhancing CI/CD reliability by ensuring every individual commit is a stable, self-contained unit that passes all automated tests before being merged.
| name | atomic-commits |
|---|---|
| description | This skill should be used for guidance on commit size, scope, and creating reviewable commits, splitting large changes, commit hygiene |
| whenToUse | Deciding when to commit, commit scope, atomic changes, splitting large PRs, commit hygiene, reviewable changes |
| whenNotToUse | Simple single-file changes, trivial fixes |
| - skill | plan-management |
| when | mapping tasks to commits |
Atomic Commits
Creating reviewable commits that capture logical units of work.
Principles
- One logical change per commit
- Commit compiles and tests pass
- Commit message explains "why"
Devloop Integration
Plan tasks map to commits:
When using /devloop:ship, you can choose:
- Single commit: Squash all completed tasks
- Atomic commits: One commit per task
Example plan:
- [x] Task 1.1: Create config skill
- [x] Task 1.2: Add parsing script
- [x] Task 1.3: Update session hook
Atomic commits would create:
feat(devloop): create local-config skill
feat(devloop): add config parsing script
feat(devloop): update session-start hook
Commit Size Guidelines
| Size | Lines | When to Commit |
|---|---|---|
| XS | <50 | Single fix, config change |
| S | 50-200 | One feature, one refactor |
| M | 200-500 | Feature with tests |
| L | >500 | Consider splitting |
Devloop tasks typically align with S-M size commits.
Split Strategy
Instead of one large commit:
- Refactor/prep commit
- Core implementation commit
- Tests commit
- Documentation commit
Or with devloop: One commit per phase.
Anti-Patterns
- WIP commits with broken code
- Mixing refactoring with features
- "Fix everything" commits
- Unrelated changes bundled
When to Commit in Devloop
- After completing a plan phase
- Before running
/devloop:fresh - At checkpoints
- Before switching context