name	git-atomic-commit
description	Plan and create atomic Git commits for larger workspace changes. Use when Codex executes a multi-step plan, prepares commits, splits staged changes, or reviews whether each commit is independently coherent and buildable.

Git Atomic Commit

Use this skill when a task produces multiple logical changes or when preparing commits after a larger plan.

Core Rule

Create small, atomic commits. Each commit should represent one coherent change and should be understandable, reviewable, and preferably buildable on its own.

Commit Splitting

Split unrelated changes into separate commits, even if they were implemented during the same plan.
Group code, tests, fixtures, config, and docs only when they directly support the same logical change.
Do not create a commit that depends on code introduced only by a later commit.
Put prerequisites before dependents: types/helpers first, callers next, integration or polish after.
Avoid one large "everything" commit when the work can be reviewed as independent steps.

Buildability

Prefer every commit to compile or build successfully.
If a commit introduces a new call site, include the required function, type, import, feature flag, and configuration in the same commit or an earlier commit.
If a temporary non-buildable commit is unavoidable, avoid leaving it in the final history; squash or reorder before presenting the result.
When validation is available, run the narrowest relevant build/test after each commit-sized unit or before committing that unit.

Workflow

Inspect the working tree with git status --short and identify unrelated file groups.
Review diffs with git diff and decide the intended commit sequence before staging.
Stage only one logical unit at a time using pathspecs or interactive staging.
Verify the staged diff with git diff --cached.
Commit with a message that follows the workspace commit message convention.
Repeat until all intended changes are committed, leaving unrelated user changes untouched.

Examples

Good split:

Commit A: feat(Config): 添加 alist2strm 配置结构
Commit B: feat(Alist2Strm): 实现 strm 生成流程
Commit C: test(Alist2Strm): 覆盖路径转换逻辑

Bad split:

Commit A calls build_strm_path() but does not define it.
Commit B defines build_strm_path() afterward.
Commit C mixes config parsing, runner refactor, README edits, and unrelated formatting.

Git Atomic Commit

Use this skill when a task produces multiple logical changes or when preparing commits after a larger plan.

Core Rule

Create small, atomic commits. Each commit should represent one coherent change and should be understandable, reviewable, and preferably buildable on its own.

Commit Splitting

Split unrelated changes into separate commits, even if they were implemented during the same plan.

Group code, tests, fixtures, config, and docs only when they directly support the same logical change.

Do not create a commit that depends on code introduced only by a later commit.

Put prerequisites before dependents: types/helpers first, callers next, integration or polish after.

Avoid one large "everything" commit when the work can be reviewed as independent steps.

Buildability

Prefer every commit to compile or build successfully.

If a commit introduces a new call site, include the required function, type, import, feature flag, and configuration in the same commit or an earlier commit.

If a temporary non-buildable commit is unavoidable, avoid leaving it in the final history; squash or reorder before presenting the result.

When validation is available, run the narrowest relevant build/test after each commit-sized unit or before committing that unit.

Workflow

Inspect the working tree with git status --short and identify unrelated file groups.

Review diffs with git diff and decide the intended commit sequence before staging.

Stage only one logical unit at a time using pathspecs or interactive staging.

Verify the staged diff with git diff --cached.

Commit with a message that follows the workspace commit message convention.

Repeat until all intended changes are committed, leaving unrelated user changes untouched.

Examples

Good split:

Commit A: feat(Config): 添加 alist2strm 配置结构

Commit B: feat(Alist2Strm): 实现 strm 生成流程

Commit C: test(Alist2Strm): 覆盖路径转换逻辑

Bad split:

Commit A calls build_strm_path() but does not define it.

Commit B defines build_strm_path() afterward.

Commit C mixes config parsing, runner refactor, README edits, and unrelated formatting.

git-atomic-commit