Surgical edits

Skill fbsmna-coder/karpathy-pro-max/skills/surgical-edits

Stop Claude Code from hallucinating — Karpathy-grade discipline in 8 skills

Install

npx -y skills add fbsmna-coder/karpathy-pro-max --skill surgical-edits

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Touch only what the request requires. Use when editing existing code to prevent scope creep, accidental refactors, formatting drift, and changes to code you do not understand.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.5 KB, as published. Nobody here has run it

Surgical Edits

LLMs drift. While editing one function, they "improve" the import order, reformat a nearby block, rename a variable that bothered them, and change a comment they didn't fully understand. Each of these is a separate change the user did not ask for, and each one is a place a regression can hide.

The rule

Every changed line must trace directly to the user's request.

If you cannot point at the request and say "this line exists because of that," delete the change before committing.

What to NOT touch

Formatting / whitespace in code you didn't need to modify.
Import order, even if it's "wrong."
Variable names in adjacent functions, even if they're inconsistent.
Comments you did not author, even if they look stale — you may not have the context to know if they're stale.
Dead code. Mention it. Do not delete it unless asked.
Style choices (single vs double quotes, trailing commas, etc.) that disagree with your preference but match the surrounding code.

What you SHOULD clean up

When your changes orphan something, clean up:

Imports that became unused because of YOUR changes.
Variables / parameters / functions that became unreferenced because of YOUR changes.
Tests that test removed behavior.

The distinction: pre-existing mess is not yours to fix. Mess you created is.

Style matching

Match the surrounding style even if you would do it differently. The codebase has one voice; do not introduce a second.

If the file uses snake_case and you add camelCase, you have made the codebase worse, not better — even if camelCase is "correct" in some abstract sense.

When to surface, not silently fix

If you notice something that should be changed but is outside scope:

Mention it in your end-of-task report.
Do not change it.
Do not file an issue for it unless asked.

Example

Bad:

User: "Fix the off-by-one in process_batch." Agent: fixes the off-by-one, also reformats 30 lines, renames i to index, adds 4 type hints, removes a comment that "looked stale," updates an unrelated import order.

Good:

User: "Fix the off-by-one in process_batch." Agent: changes one line. Reports: "Fixed. Note: noticed process_batch has no test for the empty-input case — leaving as-is per scope, flagging in case you want it added."