Skip to main content

minimal-diff

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.

소스 정보

저장소
weikinhuang/dotfiles
최근 소스 활동
2026년 5월 16일 03:17
감지된 SKILL.md 언어
영어
스타
21
포크
3

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
minimal-diff
description
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.
# 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 1. Identify the smallest region that must change. Prefer a targeted replacement (diff-style edit) over a whole-file rewrite. 2. Preserve the exact indentation style (spaces vs tabs, width), quoting style, and trailing punctuation (trailing commas, semicolons) used by surrounding code in the file. 3. 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. 4. 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.
GitHub에서 보기