surgical-changes
starsforks
How to install surgical-changes?
developersglobal/ai-agent-skills/surgical-changes
$npx -y skills add DevelopersGlobal/ai-agent-skills --skill surgical-changesEnforces minimal code modifications — touch only what you must. Prevents drive-by refactoring, comment deletions, and style changes unrelated to the task.
SKILL.md
| 1 | ## Overview |
| 2 | |
| 3 | Every changed line is a line the reviewer must inspect, a line that could introduce a regression, and a line that will appear in the git blame forever. Unnecessary changes are costly. |
| 4 | |
| 5 | AI agents often "improve" adjacent code, reformat files, rename variables for consistency, or delete "dead" code — all without being asked. This creates noisy diffs, unexpected behavior changes, and broken trust. |
| 6 | |
| 7 | This skill enforces a hard rule: **every changed line must trace directly to the user's request.** |
| 8 | |
| 9 | ## When to Use |
| 10 | |
| 11 | - Any time you are modifying existing code (not creating new files) |
| 12 | - When your diff is larger than you expected |
| 13 | - When reviewing your own generated changes before presenting them |
| 14 | |
| 15 | ## Process |
| 16 | |
| 17 | ### Step 1: Establish the Change Boundary |
| 18 | |
| 19 | 1. Read the task carefully. Write down exactly which files and functions need to change. |
| 20 | 2. Draw a mental boundary: *"Everything outside this boundary is out of scope."* |
| 21 | 3. List what you will NOT change, even if you'd do it differently: |
| 22 | - Adjacent functions |
| 23 | - Variable naming conventions |
| 24 | - Comment style |
| 25 | - Import order |
| 26 | - Formatting/whitespace (unless fixing a specific bug) |
| 27 | |
| 28 | **Verify:** You can name the specific functions/lines that need to change. |
| 29 | |
| 30 | ### Step 2: Make Only the Required Changes |
| 31 | |
| 32 | 4. Make the changes — and only the changes — within the defined boundary. |
| 33 | 5. If you notice something wrong outside the boundary: |
| 34 | - **Mention it in a comment** — don't fix it silently |
| 35 | - Example: *"Note: I noticed `fetchUser` has no error handling, but I'm leaving that for a separate PR."* |
| 36 | 6. If your changes made imports/variables/functions unused: remove only those created by YOUR changes. Leave pre-existing dead code alone (unless asked). |
| 37 | |
| 38 | **Verify:** No line changed that wasn't part of the defined scope. |
| 39 | |
| 40 | ### Step 3: Review Your Own Diff |
| 41 | |
| 42 | 7. Read through your diff line by line. |
| 43 | 8. For each changed line, ask: *"Why did I change this?"* |
| 44 | - If you can't answer → revert it |
| 45 | 9. Flag any changes that are purely cosmetic and ask: *"Should I include this?"* |
| 46 | |
| 47 | **Verify:** Every changed line has a clear reason directly tied to the task. |
| 48 | |
| 49 | ### Step 4: Document Scope Decisions |
| 50 | |
| 51 | 10. In your PR/commit message, explicitly note what you chose NOT to change and why: |
| 52 | - *"Did not refactor the adjacent `parseDate` function — out of scope for this fix."* |
| 53 | |
| 54 | ## Common Rationalizations (and Rebuttals) |
| 55 | |
| 56 | | Excuse | Rebuttal | |
| 57 | |--------|----------| |
| 58 | | "I improved it while I was there" | That's a separate PR. Drive-by improvements hide bugs and inflate diffs. | |
| 59 | | "The old comment was wrong" | Fix comments related to your change. Leave others for a documentation PR. | |
| 60 | | "I made the code more consistent" | Consistency PRs should be standalone. Don't bundle them. | |
| 61 | | "It's just whitespace" | Whitespace changes cause merge conflicts and obscure real diffs in blame. | |
| 62 | | "The dead code is obviously wrong" | File an issue. Don't delete pre-existing code without explicit approval. | |
| 63 | |
| 64 | ## Red Flags |
| 65 | |
| 66 | - Your diff is 3× larger than the feature size suggests |
| 67 | - You changed files that aren't related to the task |
| 68 | - You reformatted a file "while you were there" |
| 69 | - You renamed variables for consistency |
| 70 | - You deleted comments or code you didn't fully understand |
| 71 | - Your PR description says "and also fixed a few other things" |
| 72 | |
| 73 | ## Verification |
| 74 | |
| 75 | - [ ] Every changed line traces to the task description |
| 76 | - [ ] No cosmetic-only changes bundled in (or explicitly approved) |
| 77 | - [ ] Pre-existing dead code left untouched (or flagged, not deleted) |
| 78 | - [ ] Changes to adjacent unrelated code: zero |
| 79 | - [ ] Diff size is proportional to task size |
| 80 | |
| 81 | ## References |
| 82 | |
| 83 | - [simplicity-first skill](../simplicity-first/SKILL.md) |
| 84 | - [code-review skill](../code-review/SKILL.md) |
| 85 | - Karpathy: *"They still sometimes change/remove comments and code they don't sufficiently understand as side effects, even if orthogonal to the task."* |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
