Minimal Diff
When editing an existing file, change only what the task requires. Surrounding code, formatting, import order, and
whitespace stay exactly as they were. A good patch reads like a sniper shot, not a renovation.
The rule
If a line isn't part of the requested change, it doesn't move, doesn't reformat, and doesn't get "cleaned up".
This applies to:
- Whitespace and indentation outside the edit.
- Import order, key order in objects / dicts, and field order in structs.
- Trailing newlines, blank-line counts between functions.
- Quoting style (single vs double quotes), comment style, hoisted vs inline declarations.
- "While I'm here" unrelated refactors.
When this applies
Any modification to an existing file. Especially important when:
- The file is under version control and the diff will be reviewed.
- The repo has an auto-formatter - formatter churn should be its own commit, never mixed with a logic change.
- You're fixing a bug or adding a small feature in a large file.
Skip this skill when the user explicitly asks for one of:
- "Rewrite this file", "reformat this file", "reorganize these imports".
- A dedicated refactor/tidy pass that is itself the task.
How to apply
- Identify the smallest region that must change. Prefer a targeted replacement (diff-style edit) over a whole-file
rewrite.
- Preserve the exact indentation style (spaces vs tabs, width), quoting style, and trailing punctuation (trailing
commas, semicolons) used by surrounding code in the file.
- If your tooling would auto-format on save and that would touch lines outside the edit, either disable format-on-save
for this file or manually undo the unrelated hunks before committing.
- Before finalizing, diff the file against the pre-edit state and confirm every hunk is justified by the task.
Decision prompts
Ask yourself before finalizing:
- "Does this hunk exist because the task required it?" If no, revert the hunk.
- "Did I reorder imports or keys?" If yes, was the reorder requested? Revert if not.
- "Did I change quoting, trailing commas, or spacing outside the edit region?" Revert.
- "Did I use a whole-file write when a 3-line replacement would work?" Switch to the targeted edit.
Anti-patterns
- "While I'm here" renames. Rename in a separate commit with a clear message.
- Re-alphabetizing imports / keys for tidiness. If the file's existing order is inconsistent, leave it - a dedicated
sort commit is the right place for that.
- Running a formatter mid-edit and committing the combined diff. The formatter's hunks and your logic hunks should
never share a commit.
- Whole-file rewrite as the default. Even for a 10-line file, a targeted replacement makes the intent obvious.
- Converting quoting style, tab/space, or line endings opportunistically. These changes are invisible in casual
review and bloat the diff.
- Leaving trailing whitespace or blank-line changes from an editor. Strip those before committing.
Quick self-check
Before declaring the edit finished, run a diff preview (e.g. git diff <path>) and count the hunks. If the number of
hunks is larger than the number of distinct changes the task required, you have non-minimal diff to revert.
1---2name: minimal-diff3description: WHAT: Keep edits narrow - change only the lines the task requires, preserve surrounding formatting, and never rewrite a file when a targeted edit suffices. WHEN: Any modification to an existing file. DO-NOT: Reformat unrelated regions, reorder imports or keys for tidiness, normalize whitespace outside the edit, or rewrite a file with a whole-file write when a small replacement would do.4---56# Minimal Diff78When editing an existing file, change only what the task requires. Surrounding code, formatting, import order, and9whitespace stay exactly as they were. A good patch reads like a sniper shot, not a renovation.1011## The rule1213If a line isn't part of the requested change, it doesn't move, doesn't reformat, and doesn't get "cleaned up".1415This applies to:1617- Whitespace and indentation outside the edit.18- Import order, key order in objects / dicts, and field order in structs.19- Trailing newlines, blank-line counts between functions.20- Quoting style (single vs double quotes), comment style, hoisted vs inline declarations.21- "While I'm here" unrelated refactors.2223## When this applies2425Any modification to an existing file. Especially important when:2627- The file is under version control and the diff will be reviewed.28- The repo has an auto-formatter - formatter churn should be its own commit, never mixed with a logic change.29- You're fixing a bug or adding a small feature in a large file.3031Skip this skill when the user explicitly asks for one of:3233- "Rewrite this file", "reformat this file", "reorganize these imports".34- A dedicated refactor/tidy pass that is itself the task.3536## How to apply37381. Identify the smallest region that must change. Prefer a targeted replacement (diff-style edit) over a whole-file39 rewrite.402. Preserve the exact indentation style (spaces vs tabs, width), quoting style, and trailing punctuation (trailing41 commas, semicolons) used by surrounding code in the file.423. If your tooling would auto-format on save and that would touch lines outside the edit, either disable format-on-save43 for this file or manually undo the unrelated hunks before committing.444. Before finalizing, diff the file against the pre-edit state and confirm every hunk is justified by the task.4546## Decision prompts4748Ask yourself before finalizing:4950- "Does this hunk exist because the task required it?" If no, revert the hunk.51- "Did I reorder imports or keys?" If yes, was the reorder requested? Revert if not.52- "Did I change quoting, trailing commas, or spacing outside the edit region?" Revert.53- "Did I use a whole-file write when a 3-line replacement would work?" Switch to the targeted edit.5455## Anti-patterns5657- **"While I'm here" renames.** Rename in a separate commit with a clear message.58- **Re-alphabetizing imports / keys for tidiness.** If the file's existing order is inconsistent, leave it - a dedicated59 sort commit is the right place for that.60- **Running a formatter mid-edit and committing the combined diff.** The formatter's hunks and your logic hunks should61 never share a commit.62- **Whole-file rewrite as the default.** Even for a 10-line file, a targeted replacement makes the intent obvious.63- **Converting quoting style, tab/space, or line endings opportunistically.** These changes are invisible in casual64 review and bloat the diff.65- **Leaving trailing whitespace or blank-line changes from an editor.** Strip those before committing.6667## Quick self-check6869Before declaring the edit finished, run a diff preview (e.g. `git diff <path>`) and count the hunks. If the number of70hunks is larger than the number of distinct changes the task required, you have non-minimal diff to revert.