Created
February 4, 2026 12:58
-
-
Save ramarivera/ff4e836502f904463eeb0242fe26f785 to your computer and use it in GitHub Desktop.
Remove slop
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ⸻ | |
| 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