jonfazzaro Context marker
🔹
When the skill activates, begin the first commentary update with 🔹 and a concise Using micro-commits ... announcement. Do not repeat the marker on later updates unless another skill activates.
Micro-commits
Commit early and often to move forward quickly and safely. Each commit is a safety checkpoint: a known-good state you can return to. Small, focused commits make history readable, reversals cheap, and collaboration smooth.
Credit for the original rationale and examples that informed this skill.
When to Commit
Commit at every natural green checkpoint — do not batch up multiple logical changes into one commit:
- After meeting an expectation (green): the new expectation + the minimal code to meet it
- After each design/refactor step: one design change per commit
- After any isolated logical change: a rename, a moved file, a configuration update
If you are not using specs, commit after any coherent unit of work that leaves the code in a working state.
Commit Message Format
Use short, lowercase messages that describe what changed, not why:
| Phase | Prefix | Example |
|---|---|---|
| New behavior (green spec) | feat: |
feat: zero plus a number equals that number |
| Design / refactor | design: |
design: extract payment calculator |
| Fix | fix: |
fix: off-by-one in pagination |
| Other (config, docs, tooling) | no prefix | add eslint config |
Keep messages under 72 characters. No periods. No past tense ("added") — use present tense ("add") or noun phrases ("zero plus a number equals that number").
Process
- Verify the code is in a green / working state before committing.
- Stage only the files relevant to this commit (
git add -pfor partial staging when needed). - Inspect the staged diff and remove unrelated user work.
- Write the commit message using the format above.
- Commit.
Never commit broken or red code. If something is partially done, stash or leave it unstaged.
Integration with Continuous Specification
In the CS cycle, commit at these moments:
- After each expectation reaches its green checkpoint: commit the expectation and minimal production behavior together.
- After each design change: one commit per change using the
design:prefix. - Do NOT commit during the red phase (unmet expectation). Wait for green.
Example sequence:
feat: zero plus a number equals that number
feat: add two positive numbers
design: extract addition into calculator class
feat: add two negative numbers
design: rename add to sum
Reverting
If something goes wrong, micro-commits make recovery precise:
git revert HEAD— undo the last commit safelygit reset --soft HEAD~1— undo last commit, keep changes stagedgit log --oneline— scan the history to find the last good state