micro-commitslisted

## 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](credits.md) 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`