Split a large or mixed Git working tree into multiple focused local commits. Use when changes span unrelated concerns, combine refactors with behavior changes, mix generated files with source edits, or contain separable hunks in the same file, and Codex needs to stage one logical batch at a time, invoke `$git-commit` to draft the staged commit message, present the staged batch for user confirmation, run `git commit` only after the user explicitly approves that batch, and repeat without pushing.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Split a large or mixed Git working tree into multiple focused local commits. Use when changes span unrelated concerns, combine refactors with behavior changes, mix generated files with source edits, or contain separable hunks in the same file, and Codex needs to stage one logical batch at a time, invoke `$git-commit` to draft the staged commit message, present the staged batch for user confirmation, run `git commit` only after the user explicitly approves that batch, and repeat without pushing.
Split Commits
Turn an overgrown working tree into a short sequence of focused local commits. Assemble each commit in the index first, hand it to $git-commit for the message, then stop for user confirmation before running git commit. Do not push as part of this skill.
Workflow
Inspect the current Git state.
git status --short
git diff --stat
git diff --cached --stat
Decide whether the work should be split. Split when one or more of these are true:
the changes contain multiple independent concerns
refactors and behavior changes are mixed
tests belong to only one part of the implementation
generated or lock files should travel with only one subset
a file contains unrelated hunks that would produce a misleading single commit
Write a short commit plan before staging.
Aim for 2-5 commits.
Give each commit one purpose and one likely Conventional Commit type.
Order commits so each one is understandable on its own.
Respect the current index.
If staged changes already match the next planned commit, keep them.
If staged changes mix unrelated concerns, stop and ask before repartitioning the index.
Stage only the next logical batch.
Use git add <path> for whole files.
Use git add -p <path> when only some hunks belong.
Avoid git add . unless the remaining work is intentionally one batch.
Verify the staged batch.
git diff --cached --stat
git diff --cached
Confirm no secrets, unrelated files, or accidental churn are included.
Invoke $git-commit and use it to draft the commit message from the staged diff only.
Review the proposed message against the staged diff.
Keep it if accurate.
Tighten it if it overstates the change or merges multiple concerns in the wording.
If $git-commit indicates the staged set is still mixed, do not commit it. Refine the staged batch and rerun $git-commit.
Present the staged diff summary and the finalized message to the user, then ask for explicit confirmation for that one commit.
Wait for confirmation before changing Git history.
If the user declines, refine the staged batch or the message and ask again.
Run git commit with the finalized message only after the user explicitly approves that staged batch.
Re-run git status --short and continue with the next planned batch until the intended local commits are created.
Grouping Heuristics
Prefer splitting by intent, not by directory alone.
Good commit boundaries:
a bug fix with the tests that prove it
a pure rename or move isolated from behavior changes
a mechanical formatting or codemod sweep isolated from semantic edits
a dependency bump paired with the code or config required for that bump
documentation that belongs to a single feature or refactor
Poor commit boundaries:
"backend files" vs "frontend files" when both implement one feature
tests separated from the code they validate unless the repo already expects that pattern
arbitrary file-count balancing
one commit per file when the behavior change spans several files
If two changes cannot be described honestly with one subject line, they likely deserve separate commits.
Guardrails
Do not push.
Do not amend unless the user explicitly asks.
Do not run git commit until the user explicitly approves the current staged batch and message.
Do not use destructive commands such as git reset --hard or git checkout --.
Do not silently unstage or restage a mixed index; ask first if the existing staged state must be reshaped.
Do not ask $git-commit to summarize unstaged changes. It must see staged changes only.
Stop and ask if the remaining edits are too entangled to split without guessing intent.
Completion
Before finishing:
ensure every requested local commit exists
leave any intentionally uncommitted changes in the working tree
report the created commit subjects or SHAs to the user
