Installs into .claude/skills of the current project.
Are you the author of Surgical Changes?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/yuchi-chang-surgical-changes)
---
name: surgical-changes
description: Use when editing existing code — bug fixes, small features, or any change inside a codebase you didn't just write
---
# 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.
