deslop

name	deslop
description	Use when cleaning up AI-generated code slop — removes stale comments, delegates to code-simplifier, and proposes identifier renames with user approval

Deslop — AI Slop Removal Workflow

Overview

Deslop cleans up AI-generated code in 3 phases:

1. Comment Cleanup — auto-removes obvious slop comments
2. Code Simplification — delegates to the code-simplifier subagent
3. Rename & Inline — proposes verbose identifier renames and wrapper inlining for user approval

Prerequisites

Before starting, you need a file list and phase selection. These come from the /deslop command's argument parsing. If invoked directly (not via command), ask the user what files to target and default to git diff.

Phase 1: Comment Cleanup

Remove slop comments automatically. No user approval needed — these are unambiguously bad.

Read references/comment-patterns.md for the complete pattern catalog.

Steps

1. Collect target files. Use the file list from the command. Filter to only text/code files (skip images, binaries, lock files).

2. Scan each file. Read the file contents. Identify comments matching the three categories from the reference:

   • Category A: Obvious/stale comments (restating code, empty TODOs, section dividers, closing-brace comments)
   • Category B: Commented-out code (dead code, commented console.log/debugger/imports)
   • Category C: Marker comments (AI attribution, inline changelogs, unjustified lint suppressions)

3. Remove identified comments. Use the Edit tool to remove each identified comment. When removing a comment:

   • Remove the entire comment line (including the line break) if the line contains only the comment
   • Remove only the comment portion if it's an inline comment after code
   • Remove blank lines left behind by removed block comments (but don't collapse more than one blank line)

4. Track removals. Keep a running count per file, per category.

5. Output the summary. After processing all files, output a summary table:

Phase 1: Comment Cleanup
  src/auth.ts — removed 4 comments (2 obvious, 1 commented-out, 1 marker)
  src/utils.ts — removed 2 comments (2 obvious)
  Total: 6 comments removed across 2 files

If no comments were found, output:

Phase 1: Comment Cleanup
  No slop comments found. Code is clean.

Important Rules

• Do NOT remove comments that explain WHY something is done (rationale, trade-offs, workarounds)
• Do NOT remove license headers or legal notices
• Do NOT remove comments that contain URLs to issues, specs, or documentation
• Do NOT remove // eslint-disable or @ts-ignore that have an explanation after them
• Do NOT auto-remove // HACK, // FIXME, or // XXX — flag them in the summary as "needs review" but leave them in place. The user can decide.
• When in doubt, leave the comment. Phase 1 is for obvious slop only.

Phase 2: Code Simplification

Delegate to the official code-simplifier subagent. This handles redundancy elimination, readability improvements, modernization, and structural improvements.

Steps

1. Launch code-simplifier. Use the Task tool to dispatch a subagent:

   • subagent_type: Use the general-purpose agent type
   • In the prompt, instruct it to act as the code-simplifier agent
   • Pass the list of target files
   • Tell it to focus on:
     • Replacing verbose custom implementations with built-in language features
     • Simplifying complex conditional logic (guard clauses, early returns)
     • Reducing nesting levels
     • Consolidating duplicated logic patterns
     • Updating to modern language idioms
   • Tell it to NOT change external behavior — only internal structure

2. Wait for completion. The subagent will make edits directly.

3. Report results. After the subagent completes, output:

Phase 2: Code Simplification
  [Summary of what the code-simplifier changed]

If the subagent found nothing to simplify:

Phase 2: Code Simplification
  No simplification opportunities found.

Phase 3: Rename & Inline Proposals

Analyze code for verbose identifiers and trivial wrappers, then propose changes for user approval.

Steps

1. Scan for verbose identifiers. Read each target file and identify:

   • Verbose function names: Names that can be shortened without losing meaning. Examples:
     • handleUserAuthenticationProcess → authenticate
     • isCurrentlyLoadingData → isLoading
     • getAllUserDataFromDatabase → getUsers
     • performDataValidationCheck → validate
   • Redundant prefixes/suffixes: Repeated context in nested access:
     • userData.userEmail → userData.email
     • configSettings.settingsTimeout → configSettings.timeout
     • errorHandler.handleError → errorHandler.handle
   • Overqualified variable names: Names with unnecessary type or context suffixes:
     • userArray → users
     • nameString → name
     • isActiveBoolean → isActive
     • resultData → result

2. Scan for trivial wrappers. Identify functions that:

   • Call exactly one other function with the same or fewer arguments
   • Add no logic, no error handling, no transformation
   • Exist only as indirection
   • Example: function getUser(id) { return userService.get(id); } — inline the call

3. Scan for unnecessary abstractions. Identify:

   • Single-use helper functions that obscure a simple operation
   • Constants that are used once and whose name adds no clarity over the value
   • Wrapper classes with one method that just delegates

4. Build proposal list. For each finding, create a proposal with:

   • File path and line number
   • Current name/code
   • Proposed name/code
   • Brief rationale

5. Present to user. Use AskUserQuestion with multiSelect: true:

   question: "Phase 3 found these rename and inline opportunities. Select which to apply:"
   options:
     - label: "authenticateUser → authenticate"
       description: "src/auth.ts:42 — name is redundant in AuthService context"
     - label: "Inline getUser wrapper"
       description: "src/services.ts:15 — trivial wrapper around userRepo.find()"
     - label: "userData.userEmail → userData.email"
       description: "src/profile.ts:28 — redundant 'user' prefix"
   

   AskUserQuestion supports max 4 options. If there are more than 4 proposals, batch them into multiple questions grouped by type (renames first, then inlines, then abstractions).

6. Apply selected changes. For each user-approved proposal:

   • Use Edit tool with replace_all: true for renames (to catch all occurrences)
   • For inlined wrappers, remove the wrapper function and replace all call sites
   • For unnecessary abstractions, inline the code at the usage site and remove the abstraction

7. Output summary.

Phase 3: Rename & Inline
  Applied 3 of 5 proposals:
    ✓ authenticateUser → authenticate (src/auth.ts, 4 occurrences)
    ✓ Inlined getUser wrapper (src/services.ts, removed wrapper + 2 call sites updated)
    ✓ userData.userEmail → userData.email (src/profile.ts, 1 occurrence)
    ✗ Skipped: isLoading rename (user declined)
    ✗ Skipped: resultData rename (user declined)

Important Rules

• Never rename exported/public API identifiers without highlighting that it's a breaking change.
• Never rename identifiers that match an interface, protocol, or API contract.
• For renames, always use replace_all: true to catch every occurrence in the file. Also search other files in the target set for cross-file references.

Completion

After all phases complete (or whichever phases were selected), output a final summary:

Deslop complete.
  Phase 1: N comments removed across M files
  Phase 2: [code-simplifier summary]
  Phase 3: N of M proposals applied