| name | git-atomic-commit |
| description | Plan and create atomic Git commits for larger coding tasks. Use when Codex implements a multi-step change, prepares commits, splits a large diff, reviews commit boundaries, or must ensure each commit is coherent, independently buildable, and does not depend on code introduced only in a later commit. |
Git Atomic Commit
Goal
Split larger work into small, reviewable Git commits where each commit has one intent and can build on its own. Never bundle unrelated changes just because they were edited in one working session.
Use this skill to decide commit boundaries and ordering. When a boundary needs a final commit message, invoke or consult $git-commit-message instead of duplicating message rules here.
Atomic Commit Rules
- Put one logical intent in each commit.
- Keep dependency order correct: if commit A calls a function, type, module, feature flag, or test helper, commit A must also introduce it or depend on an earlier commit that does.
- Keep each commit buildable whenever practical. For this Rust repository, prefer running
cargo check after each planned commit boundary and cargo test for behavior changes.
- Avoid "fix the previous commit" commits while still preparing local history; fold follow-up fixes into the commit that introduced the issue.
- Separate mechanical changes from behavior changes when possible.
- Separate generated or upstream API updates from handwritten code when possible.
- Separate tests from implementation only when the implementation commit is still meaningful and buildable without the new tests.
Boundary Examples
Prefer boundaries like:
- sync upstream API definitions;
- add request/response models for one feature area;
- implement one client feature after its models exist;
- add tests for the smallest behavior slice they validate;
- perform one mechanical refactor before behavior changes that depend on it;
