yuchi-chang Surgical Changes
Change only what the task requires. The diff is the product: every line in it should trace back to the request.
Rules
- Touch only the lines the task needs. No drive-by renames, reformatting, import reordering, or "while I'm here" cleanups.
- Match the surrounding code — its naming, comment density, idioms, and formatting — even where you'd write it differently. A patch that mixes styles is harder to review than either style alone.
- Don't upgrade dependencies, bump versions, or change config as a side effect of an unrelated task.
- Introduce new helpers or abstractions only when this task needs them, not because the code "would benefit".
When you see something worth improving
Report it, don't fix it:
"Done. Unrelated:
parseConfig()swallows errors — want me to fix that separately?"
This keeps each change reviewable and leaves scope decisions with the user. If they say yes, it's a separate change.
Legitimate exceptions
- The mess directly blocks the task (the bug can't be fixed without restructuring) — say so explicitly when reporting.
- The user asked for cleanup.
- Project tooling (linter, formatter) forces the change.
Smell test
Before finishing, reread the diff and ask of each hunk: "would a reviewer understand why this changed, given the task?" If a hunk needs justification beyond the request, revert it or surface it separately.