Diff Cleanup
Remove AI-generated bloat from a feature branch's diff.
Three required rules
1. Diff against the base branch, not the working tree
git fetch origin --quiet 2>/dev/null
BASE=$(git merge-base HEAD origin/main 2>/dev/null \
|| git merge-base HEAD origin/master 2>/dev/null \
|| git rev-parse HEAD~1)
git diff "$BASE"...HEAD
git diff alone only shows the working tree. Branch-scope cleanup needs the whole feature branch. If you cannot determine the base, ask.
2. Check authorship before removing anything
For each candidate removal:
git blame -L <start>,<end> -- <file>
Only remove lines whose commit is on the current feature branch (after $BASE). Lines predating the branch are human-authored. Leave them alone, even if they look slop-like.
3. Respect the design vs. style boundary
You are removing low-value tokens within a chosen design. You are not redesigning.
| In scope |
Out of scope |
| Restating-the-code comments |
Whether a builder/factory pattern is justified |
| Type-system-redundant runtime guards |
Whether the function should exist at all |
| Reflowed loops with no behavior change |
Whether the data model is right |
IMPORTANT:-style emphasis on trivia |
Whether the public API is too wide |
If you find yourself wanting to redesign, stop and flag it. Do not silently rewrite.
Never touch
- Comments explaining why (business reason, workaround, non-obvious constraint)
- Defensive checks at public API boundaries or on external/untrusted input
- Lines predating the feature branch (per rule 2)
- Test code
Procedure
- Resolve
$BASE (rule 1).
git diff "$BASE"...HEAD — read the full branch diff.- For each candidate removal, run
git blame on the line range. Confirm every candidate is branch-authored (rule 2).
- Preview before applying. Group candidates by file and list each one: the line(s), the slop category, and the blame evidence. Do not edit yet.
- Approval gate. Show the preview and get explicit confirmation before removing anything. If the user says "just do it," still state the removal count and categories, then proceed only on explicit confirmation. A removal the user cannot see coming is a wrong removal.
- Apply removals with Edit. Do not rewrite logic.
- Verify after cleanup. Removing code changes behavior, so confirm it did not break anything:
- Re-run the project linter on touched paths.
- Run a focused test on touched paths (or the smallest meaningful command). If none exist, say so.
- If a removed line turns out load-bearing (a test fails, lint errors), revert that removal and report it — it was not slop.
- Optionally load
quality-reviewer for a focused pass on the cleaned diff.
git diff "$BASE" --stat to confirm the final shape, including the
uncommitted cleanup. Do not use git diff "$BASE"...HEAD --stat here: the
...HEAD form stops at the committed branch tip and omits edits just made
in the working tree.- Report: categories removed, design concerns flagged but not touched, verification results, and final stat.
Common Mistakes
- Applying removals without showing a preview first. The user cannot catch a wrong removal after the edit.
- Treating a redundant-looking guard as slop when it protects a dynamic call path or external input. Verify with tests, not intuition — a failed test means revert.
- Cleaning up merge-commit deltas.
git diff "$BASE"...HEAD on a branch with merges from main includes their noise; if the branch has merges, scope to feature-branch commits only.
- Running cleanup without verifying afterward. Removing code changes behavior; confirm with lint and tests before claiming done.
- Removing lines predating the feature branch.
git blame is the authority, not your sense of style.
1---2name: diff-cleanup3description: Clean an existing diff of AI-generated bloat, redundant comments, needless abstractions, or overcomplication. Use when the user asks to remove AI slop or simplify the diff.4---56# Diff Cleanup78Remove AI-generated bloat from a feature branch's diff.910## Three required rules1112### 1. Diff against the base branch, not the working tree1314```bash15git fetch origin --quiet 2>/dev/null16BASE=$(git merge-base HEAD origin/main 2>/dev/null \17 || git merge-base HEAD origin/master 2>/dev/null \18 || git rev-parse HEAD~1)19git diff "$BASE"...HEAD20```2122`git diff` alone only shows the working tree. Branch-scope cleanup needs the whole feature branch. If you cannot determine the base, ask.2324### 2. Check authorship before removing anything2526For each candidate removal:2728```bash29git blame -L <start>,<end> -- <file>30```3132**Only remove lines whose commit is on the current feature branch (after `$BASE`).** Lines predating the branch are human-authored. Leave them alone, even if they look slop-like.3334### 3. Respect the design vs. style boundary3536You are removing **low-value tokens within a chosen design**. You are not redesigning.3738| In scope | Out of scope |39|---|---|40| Restating-the-code comments | Whether a builder/factory pattern is justified |41| Type-system-redundant runtime guards | Whether the function should exist at all |42| Reflowed loops with no behavior change | Whether the data model is right |43| `IMPORTANT:`-style emphasis on trivia | Whether the public API is too wide |4445If you find yourself wanting to redesign, **stop and flag it**. Do not silently rewrite.4647## Never touch4849- Comments explaining **why** (business reason, workaround, non-obvious constraint)50- Defensive checks at **public API boundaries** or on **external/untrusted input**51- Lines predating the feature branch (per rule 2)52- Test code5354## Procedure55561. Resolve `$BASE` (rule 1).572. `git diff "$BASE"...HEAD` — read the full branch diff.583. For each candidate removal, run `git blame` on the line range. Confirm every candidate is branch-authored (rule 2).594. **Preview before applying.** Group candidates by file and list each one: the line(s), the slop category, and the blame evidence. Do not edit yet.605. **Approval gate.** Show the preview and get explicit confirmation before removing anything. If the user says "just do it," still state the removal count and categories, then proceed only on explicit confirmation. A removal the user cannot see coming is a wrong removal.616. Apply removals with Edit. Do not rewrite logic.627. **Verify after cleanup.** Removing code changes behavior, so confirm it did not break anything:63 - Re-run the project linter on touched paths.64 - Run a focused test on touched paths (or the smallest meaningful command). If none exist, say so.65 - If a removed line turns out load-bearing (a test fails, lint errors), revert that removal and report it — it was not slop.66 - Optionally load `quality-reviewer` for a focused pass on the cleaned diff.678. `git diff "$BASE" --stat` to confirm the final shape, including the68 uncommitted cleanup. Do not use `git diff "$BASE"...HEAD --stat` here: the69 `...HEAD` form stops at the committed branch tip and omits edits just made70 in the working tree.719. Report: categories removed, design concerns flagged but not touched, verification results, and final stat.7273## Common Mistakes7475- Applying removals without showing a preview first. The user cannot catch a wrong removal after the edit.76- Treating a redundant-looking guard as slop when it protects a dynamic call path or external input. Verify with tests, not intuition — a failed test means revert.77- Cleaning up merge-commit deltas. `git diff "$BASE"...HEAD` on a branch with merges from main includes their noise; if the branch has merges, scope to feature-branch commits only.78- Running cleanup without verifying afterward. Removing code changes behavior; confirm with lint and tests before claiming done.79- Removing lines predating the feature branch. `git blame` is the authority, not your sense of style.
gzb1128