surgical-changes-with-checkpointslisted

# Surgical Diffs, Reviewable Checkpoints, Evidence-Citing Commits Change exactly what the task requires and nothing more. Save a known-good version before you risk breaking things, and write each commit so a stranger can see what changed, why, and what proved it correct. ## When to use Every time you edit a file, stage a change, or write a commit message. Especially before edits that could break a working state: migrations, dependency bumps, refactors, infra changes, anything touching code you don't fully understand yet. Red-flag thoughts that mean STOP and apply this skill: - "While I'm in here, I'll also clean up / rename / reformat this." - "I'll just commit everything together, it's all related." - "I don't need a checkpoint, this change is small." - "The commit message is obvious from the diff." - "I'll tidy the surrounding code so it's consistent." ## The rule 1. **Bound the change to the stated intent.** Restate the goal in one sentence. Touch only what that sentence requires. If you find unrelated improvements, note them separately — do not fold them in. A diff that says "no content edits; no code touched" is a feature, not a limitation. 2. **Match existing conventions.** Mirror the surrounding code's style, naming, error handling, and file layout. The smallest correct diff is the one a reviewer barely notices. 3. **Checkpoint before risky work.** Commit the current working state first ("checkpoint: working X before Y") so there is always a version to fall back