id-slop
Skill5 starsChanged 6 months agoMITView on GitHub
Identify AI-generated code slop in the codebase - useless comments, backward compatibility hacks, deprecation notices, dead code, and other technical debt left by AI assistants. Use when user says "id slop", "identify slop", "find slop", or "code cleanup scan". Generates a removal plan in temp/ and validates it with dry walkthrough.
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- Trecek/useful-claude-skillsedited, first seen Mar 26, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- Trecek/useful-claude-skills★ 199% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository23 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- audit-archSkill
- audit-bugsSkill
- audit-cohesionSkill
- audit-defense-standardsSkill
- audit-testsSkill
- chart-courseSkill
- check-bearingSkill
- design-guardsSkill
- elaborate-phaseSkill
- make-arch-diagSkill
- make-reqSkill
- make-scenariosSkill
- promote-to-mainSkill
- render-recipeSkill
- review-promotionSkill
- update-architectureSkill
- update-reqsSkill
- update-specsSkill
- validate-auditSkill
- verify-diagSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 8 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 28
Remove code without creating a removal plan first
- Distinctive: line 33
Use subagents for parallel exploration
- Very specific: line 34
Write the slop removal plan to temp/id-slop/ directory
- Distinctive: line 36
Run dry walkthrough on the generated plan
- Distinctive: line 134
Test scaffolding left in production code
- Distinctive: line 216
After subagents complete, organize findings by:
- Very specific: line 225
Write a structured removal plan to: temp/id-slop/slop_removal_plan_{YYYY-MM-DD_HHMMSS}.md
- Distinctive: line 291
After generating the removal plan, invoke the dry walkthrough skill:
- Distinctive: line 329
Use these regex patterns for searching:
- Distinctive: line 364
Do NOT flag as slop:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Slop Identification Skill
Identify and catalog AI-generated code slop in the codebase. Slop is useless code patterns left behind by AI assistants during rapid development - comments that won't make sense to future readers, backward compatibility hacks, dead code, and other technical debt.
When to Use
- User says "id slop", "identify slop", "find slop"
- User wants "code cleanup" or "cleanup scan"
- User mentions "AI-generated junk" or "leftover comments"
- User asks to "find useless comments" or "remove dead code"
Critical Constraints
NEVER:
- Modify any source code files (this skill only IDENTIFIES slop)
- Remove code without creating a removal plan first
- Flag legitimate comments, documentation, or architectural patterns
- Flag TODO comments that describe actual future work
ALWAYS:
- Use subagents for parallel exploration
- Write the slop removal plan to
temp/id-slop/directory - Provide file paths and line numbers for each finding
- Run dry walkthrough on the generated plan
- Categorize slop by type for prioritized removal
Slop Categories
Category 1: Phase Reference Comments (HIGH PRIORITY)
Comments mentioning numbered phases from AI implementation plans that won't make sense to future readers.
Patterns to detect:
Phase [0-9]in comments or docstrings# Phase 1:,# Phase 2:, etc.- References to "implementation phase" or "migration phase" with numbers
Part of Phase Xcomments
Example slop:
# Phase 5: Migrate Checkpoint and Session Management
def migrate_session(): # Part of Phase 2 migrationCategory 2: Backward Compatibility Hacks (HIGH PRIORITY)
Parameters or code kept solely for "API compatibility" that's no longer needed.
Patterns to detect:
kept for API compatibilitykept for backward compatibilityunused but kept forignored - kept for- Parameters that are documented as "unused" or "ignored"
Example slop:
use_file_lock: bool = True, # Ignored - kept for API compatibility
log_dir: Optional[Path] = None, # Ignored - kept for API compatibilityCategory 3: Removed Code Comments (MEDIUM PRIORITY)
Comments explaining what was removed without explaining what replaced it.
Patterns to detect:
removed in Phaseno longer neededNOTE: X removed- References to deleted features or functions
Example slop:
# NOTE: csv_export removed in Phase 4. Use simple 'export' task.
# auth_manager removed - now handled by middlewareCategory 4: Deprecation Notices (MEDIUM PRIORITY)
Comments marking code as deprecated without removal timeline or replacement guidance.
Patterns to detect:
deprecatedwithout clear migration path@deprecateddecorators on live codewill be removedwithout version/date- Stale deprecation warnings
Category 5: Fallback/Workaround Code (HIGH PRIORITY)
Fallback logic that masks errors instead of failing fast.
Patterns to detect:
try: ... except: passblocks that swallow all exceptions# Silently ignorecomments- Fallback methods that don't log the original error
ignore_errors=Truewithout logging
Example slop:
try:
result = risky_operation()
except:
pass # Silently ignore errorsCategory 6: Type System Bypasses (LOW PRIORITY)
Comments that bypass type checking instead of fixing the actual type issue.
Patterns to detect:
# type: ignorewithout explanation# noqawithout specific error codecast()calls that don't make type sense
Example slop:
entry.status = status # type: ignore
return wrapper # type: ignoreCategory 7: Dead Placeholder Code (MEDIUM PRIORITY)
Stub implementations, placeholder nodes, or scaffolding never replaced.
Patterns to detect:
- Functions with only
passor...bodies placeholderorstubin function names# TODO: implementwithout implementation- Test scaffolding left in production code
Example slop:
def find_next_placeholder(state):
"""Placeholder node for testing."""
passCategory 8: Unreachable Code Comments (LOW PRIORITY)
Comments explaining why code is unreachable or can't happen.
Patterns to detect:
# This should be unreachable# Acknowledge unused parameter# satisfies mypyfor dead code paths- Defensive code for impossible states
Example slop:
# This should be unreachable if retry_attempts > 0, but satisfies mypy
raise RuntimeError("Unreachable")Category 9: Commented-Out Code (HIGH PRIORITY)
Code blocks that are commented out instead of deleted.
Patterns to detect:
- Multi-line commented code blocks
# old_function()style commented calls# return old_valuecommented returns
Category 10: Dead Code (HIGH PRIORITY)
Unused functions, classes, methods, imports, variables, and constants that are never referenced anywhere in the codebase.
Patterns to detect:
- Functions/methods with no callers
- Classes never instantiated or subclassed
- Imports not used in the module
- Variables/constants assigned but never read
- Module-level code that serves no purpose
Investigation Workflow
Step 1: Launch Parallel Subagents
Spawn 4-6 Explore subagents to scan different slop categories simultaneously:
Subagent 1: Phase References & Deprecation
- Search for "Phase [0-9]" patterns in comments
- Search for "deprecated" markers
- Search for "removed in" comments
Subagent 2: Backward Compatibility & Fallbacks
- Search for "kept for" compatibility patterns
- Search for "ignored" parameters
- Search for silent error handling
Subagent 3: Dead Code & Placeholders
- Search for placeholder/stub functions
- Search for unused imports with noqa
- Search for pass-only function bodies
Subagent 4: Type Bypasses & Unreachable Code
- Search for "type: ignore" without explanation
- Search for "noqa" suppressions
- Search for "unreachable" comments
Subagent 5: Commented-Out Code
- Search for multi-line comment blocks that look like code
- Search for commented function calls
- Search for # old_ patterns
Subagent 6: Dead Code
- Search for functions/classes with no callers
- Search for unused imports
- Search for assigned-but-never-read variablesStep 2: Consolidate Findings
After subagents complete, organize findings by:
- File path
- Line number(s)
- Slop category
- Priority (HIGH/MEDIUM/LOW)
- Removal action (delete line, delete block, refactor)
Step 3: Generate Removal Plan
Write a structured removal plan to: temp/id-slop/slop_removal_plan_{YYYY-MM-DD_HHMMSS}.md
The plan should follow this format:
# Slop Removal Plan
**Date:** {YYYY-MM-DD}
**Scope:** {directories scanned}
**Total Findings:** {count}
## Summary by Category
| Category | Count | Priority |
|----------|-------|----------|
| Phase References | X | HIGH |
| Backward Compatibility | X | HIGH |
| ... | ... | ... |
## Phase 1: High Priority - Phase Reference Comments
### Objective
Remove all phase reference comments that won't make sense to future readers.
### Files to Modify
- `path/to/file.py:LINE`: Remove comment "# Phase 5: ..."
- `path/to/file.py:LINE-LINE`: Remove docstring section mentioning phases
### Implementation Steps
1. Delete line X in file.py containing "Phase 5" comment
2. Delete lines X-Y in file2.py containing phase docstring
...
### Success Criteria
- [ ] No "Phase [0-9]" patterns remain in comments
- [ ] Code still functions correctly
### Verification
```bash
grep -rn "Phase [0-9]" src/ --include="*.py" | grep -v "test"Phase 2: High Priority - Backward Compatibility Hacks
Objective
Remove unused parameters kept for backward compatibility.
Files to Modify
...
Phase N: Final Verification
Verification Commands
# Run linting/formatting checks and full test suiteSuccess Criteria
- All tests pass
- No linting errors
- No functional regressions
### Step 4: Run Dry Walkthrough
After generating the removal plan, invoke the dry walkthrough skill:
Now running dry walkthrough on the slop removal plan...
### Step 5: Report Summary
Output to terminal:
Slop Identification Complete
Plan: temp/id-slop/slop_removal_plan_{YYYY-MM-DD_HHMMSS}.md Total Findings: {count}
By Priority
- HIGH: {count} items (should fix immediately)
- MEDIUM: {count} items (fix when touching these files)
- LOW: {count} items (fix opportunistically)
By Category
- Phase References: {count}
- Backward Compatibility: {count}
- Removed Code Comments: {count}
- Fallback/Workaround Code: {count}
- Dead Placeholder Code: {count}
- Type Bypasses: {count}
- Dead Code: {count}
Next Steps
- Review the plan at temp/id-slop/slop_removal_plan_{YYYY-MM-DD_HHMMSS}.md
- Dry walkthrough has been run - check for any issues
- Implement the plan phase by phase
## Search Patterns Reference
Use these regex patterns for searching:
```bash
# Phase references
grep -rn "Phase [0-9]" --include="*.py"
grep -rn "# Phase" --include="*.py"
# Backward compatibility
grep -rn "kept for.*compatibility" --include="*.py"
grep -rn "ignored.*kept for" --include="*.py"
# Removed code
grep -rn "removed in Phase" --include="*.py"
grep -rn "no longer needed" --include="*.py"
# Fallbacks
grep -rn "except:.*pass" --include="*.py"
grep -rn "ignore_errors=True" --include="*.py"
grep -rn "Silently ignore" --include="*.py"
# Type bypasses
grep -rn "# type: ignore$" --include="*.py"
grep -rn "# noqa$" --include="*.py"
# Placeholders
grep -rn "placeholder" --include="*.py"
grep -rn "def.*stub" --include="*.py"
# Unreachable
grep -rn "should be unreachable" --include="*.py"
grep -rn "satisfies mypy" --include="*.py"Exclusions
Do NOT flag as slop:
- Architecture documentation - Comments explaining design decisions
- API documentation - Docstrings explaining parameters and return values
- Legitimate TODOs - TODOs with clear descriptions of future work
- Test-specific code - Mocks, fixtures, and test utilities
- Intentional type ignores - Type ignores with explanatory comments
- Error handling with logging - Exception handlers that log errors
- Feature flags - Conditional code controlled by configuration
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

