Skip to content

Instantly share code, notes, and snippets.

@ramarivera
Created February 4, 2026 12:58
Show Gist options
  • Select an option

  • Save ramarivera/ff4e836502f904463eeb0242fe26f785 to your computer and use it in GitHub Desktop.

Select an option

Save ramarivera/ff4e836502f904463eeb0242fe26f785 to your computer and use it in GitHub Desktop.
Remove slop
description: Remove AI-generated slop from branch diff against base
argument-hint: "[base-branch] [additional-context]"
Remove AI Slop
CRITICAL: Systematically review the current branch and purge AI-generated code smell.
Step 1: Identify the Diff
Compare the current branch against the base branch (default: dev):
git diff $ARGUMENTS..HEAD --name-only # Files changed
git diff $ARGUMENTS..HEAD # Full diff
If $ARGUMENTS is empty, use dev as the base branch.
Step 1.5: User-Provided Context
Keep in mind the following additional context from the user:
$ARGUMENTS
If the user provided context:
– Use it to inform slop detection (e.g., "preserve defensive checks in auth code")
– Apply it when making judgment calls about what to remove
– Reference it in your final summary
If $ARGUMENTS is empty or only contains a branch name:
– Proceed with standard slop removal process
– Apply generic patterns and project guidelines only
Step 2: Discover Project Guidelines
Before scanning for slop, locate and read the project's standards:
Search for Guideline Files
Look for these files in the repository root and common subdirectories:
# Contribution and style guides
CONTRIBUTING.md
CONTRIBUTING
STYLE_GUIDE.md
STYLE.md
CODE_OF_CONDUCT.md
docs/contributing.md
docs/style-guide.md
.github/CONTRIBUTING.md
# AI agent instructions
AGENTS.md
CLAUDE.md
WARP.md
.claude/instructions.md
.cursor/rules/*.md
# Linter and formatter configs
.eslintrc.js
.eslintrc.json
eslint.config.js
biome.json
.prettierrc
.prettierrc.json
.editorconfig
tsconfig.json
pyproject.toml
.rubocop.yml
.golangci.yml
# Language-specific style guides
docs/nushell/nushell-style-guide.md
docs/typescript-conventions.md
docs/python-style.md
Read and Internalize Standards
For each file found:
1. Read the entire file - Don't skim, understand the rules
2. Extract key patterns:
3. Naming conventions (camelCase, kebab-case, snake_case)
4. Comment style (when to comment, when not to)
5. Error handling patterns
6. Import organization rules
7. Formatting preferences
8. Prohibited patterns or anti-patterns
9. Note enforcement level:
10. Hard rules (MUST, REQUIRED, SHALL)
11. Recommendations (SHOULD, RECOMMENDED)
12. Preferences (MAY, OPTIONAL)
Build Context-Aware Checklist
Augment the generic slop patterns (Step 3) with project-specific rules:
– If the project uses verbose comments, don't remove them
– If the project enforces defensive programming, keep those checks
– If the style guide specifies particular patterns, enforce them
– If linter rules exist, ensure code passes them
If NO guidelines are found, proceed with generic slop detection only.
Step 3: Detect Slop Patterns
Scan every changed file for these AI fingerprints:
– CommentsExplanatory comments that a human wouldn't add (e.g., // This checks if X is valid)
– Comments inconsistent with surrounding code's style
– Comments that duplicate what the code clearly does
– TODO comments added without context or tracking
– Defensive ProgrammingExtra try/catch blocks abnormal for the codebase
– Null checks on already-validated paths
– Type guards after earlier guards covered the case
– Error handling that swallows exceptions silently
– Redundant input validation in internal functions
– Type WorkaroundsCasts to any to sidestep type issues
– as unknown as T chains
– @ts-ignore or @ts-expect-error without explanation
– Overly broad generic types (any[], object, {})
– Style InconsistenciesNaming conventions that don't match the file
– Different formatting than surrounding code
– Import organization that differs from project norms
– Verbose patterns where terse ones are idiomatic
– Unnecessary FluffEmoji usage in code/comments (unless project uses them)
– Overly enthusiastic logging messages
– Placeholder strings like "TODO: Implement this"
– Console.log statements left behind
Step 4: Apply Surgical Fixes
For each file with slop:
1. Remove unnecessary comments unless project guidelines require verbose documentation
2. Simplify over-defensive code (match surrounding style and project error handling patterns)
3. Fix type issues properly instead of casting to any (follow project's typing conventions)
4. Align style with:
5. Project guidelines discovered in Step 2
6. Existing code in the file
7. Linter/formatter configurations
8. Delete debug artifacts and placeholder text
Cross-check each fix against project guidelines to ensure compliance.
DO NOT introduce new functionality or refactor beyond slop removal.
Step 5: Verify Changes
After cleanup:
# Run linter if configured
npm run lint # or equivalent (eslint, biome, ruff, etc.)
# Run formatter check if configured
npm run format # or equivalent (prettier, biome, black, etc.)
# Ensure the build still passes
npm run build # or project equivalent
# Run tests
npm test # or project equivalent
# Check the diff is smaller
git diff --stat
If linter/formatter configs were found in Step 2, ensure all checks pass.
Step 6: Report Summary
End with a summary of what you changed and guidelines compliance.
Format:
Removed [N] unnecessary comments, simplified [N] defensive blocks, fixed [N] type casts, and aligned style in [file list].
All changes verified against project guidelines: [list key guidelines followed, e.g., "CONTRIBUTING.md naming conventions, biome.json formatting rules"].
User context applied: [mention how user-provided context influenced decisions, if applicable].
If no project guidelines were found, state:
Removed [N] unnecessary comments, simplified [N] defensive blocks, fixed [N] type casts, and aligned style in [file list].
No project-specific guidelines found; applied generic slop detection only.
User context applied: [mention how user-provided context influenced decisions, if applicable].
If no user context was provided beyond the base branch, omit the "User context applied" line.
Rules
– Minimal changes - Only remove slop, don't improve working code
– Match existing style - The goal is consistency, not perfection
– Follow project guidelines - Discovered guidelines take precedence over generic patterns
– Preserve functionality - Tests must still pass
– Verify compliance - Run linter/formatter if configs exist
No scope creep - If you see unrelated issues, note them separately
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment