Commit completed units of work as you go instead of batching everything into one commit at the end. Use during any coding session that will produce more than one logical change: after each green test run, when a logical unit is complete, or before starting a risky refactor. Also applies when the user says "commit often", "checkpoint", or "commit as you go".
설치
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
Commit completed units of work as you go instead of batching everything into one commit at the end. Use during any coding session that will produce more than one logical change: after each green test run, when a logical unit is complete, or before starting a risky refactor. Also applies when the user says "commit often", "checkpoint", or "commit as you go".
Commit Often
Working code that exists only in the working tree is one bad command away
from gone. Commit at every logical unit so each step is small, reviewable,
and individually revertible.
When to commit
A logical unit is complete — one behavior added, one bug fixed, one rename
done — and the build is green.
Before starting anything risky: a cross-cutting refactor, a dependency
bump, a migration.
Before switching focus to a different part of the task.
If several files of churn have accumulated without a commit, stop and split
out what is already complete.
How to commit
Stage files explicitly (git add <file> ...), never git add . or
git add -A. Listing files catches strays before they land.
The message explains why; the diff already shows what.
Never add AI attribution: no Co-Authored-By, no "Generated with"
trailers.
Don't commit broken states to "save progress". If the build is red,
either finish the unit or stash.
Splitting accumulated work
When several units have piled up unstaged, don't flatten them into one
commit. Stage and commit them separately (git add -p for files that mix
units), in dependency order, each leaving the build green.
