Deslop

Use this after the implementation already works and before commit or push. This is not a planning workflow and not a rescue mission for broken code. It is the last pressure pass that strips noise out of an otherwise-correct diff.

Core Contract

• Deslop is a bounded helper inside the normal execution lane, not a competing end-to-end workflow.
• Default scope is changed files only. Do not widen to the whole repo unless the user asks.
• Prefer deleting or inlining over introducing fresh abstraction.
• Treat slop-scan as signal, not law. Fix the good hits. Ignore the fake ones.

What Counts As Slop

Focus on concrete smell families, not vague "AI code" vibes:

• needless abstraction: pass-through wrappers, barrel-only indirection, async noise, single-use helper layers
• duplication: repeated signatures, repeated mock setup, local copy-paste helpers
• defensive noise: empty catches, error swallowing, error obscuring where the real fix is to rethrow or narrow once
• structural fragmentation: over-fragmentation and fan-out hotspots when they land in the changed area
• placeholders and leftovers: TODO comments, dead helpers, debug scraps, fake scaffolding text

Inputs To Gather

Before cleanup, collect:

• repo root AGENTS.md
• any nested AGENTS.md or design docs that govern the changed area
• the active plan file when one exists
• the changed-files list or explicit file scope
• fresh verification evidence from the implementation pass
• the repo slop delta command output

Review Lenses

When the user explicitly asked for deslop / cleanup / refactor, run these 3 review lenses in parallel on the same context bundle:

1. Repo rules and documentation conformance
2. Type safety and source of truth
3. Simplification and overengineering

If parallel reviewers are unavailable, do the same 3 lenses locally before editing.

Procedure

1. Lock behavior first

   • If current behavior is not already protected, add or run the narrowest regression proof before cleanup edits.

2. Bound the scope

   • Build a changed-files list or explicit file scope.
   • Stay inside that scope for both review and cleanup.

3. Launch the review lenses

   • Give every reviewer the same context bundle and one assigned lens.
   • Ask for findings first, ordered by severity, with file references.

4. Run slop delta while reviewers work

   • Prefer the repo script: bun run lint:slop:delta
   • If it does not exist, fall back to slop-scan delta ...
   • Use delta, not raw repo-wide scan, to focus on added and worsened noise.

5. Synthesize before editing

   • Merge the reviewer output and delta output under:
     • How did we do?
     • Feedback to keep
     • Feedback to ignore
     • Plan of attack

6. Apply only the worthwhile fixes

   • type drift, casts, or duplicated type definitions
   • pass-through wrappers, async noise, fake helper seams
   • dead helpers, placeholder comments, debug leftovers
   • duplicate mock setup or local copy-paste helpers
   • empty or error-obscuring internal catches when the right fix is simpler

7. Re-run the narrowest affected verification

   • rerun the same tests, lint, and typecheck lanes that protect the touched area
   • if a stronger final gate already existed, rerun it after cleanup

8. Update the story

   • Make sure the active plan, commit text, and PR-facing text describe the post-deslop state, not the earlier draft.

Stop Rules

• Do not widen scope because the scan found juicy unrelated cleanup.
• Do not start product work during deslop.
• Do not add abstraction to fix abstraction.
• If generated, vendored, or fixture noise dominates the scan, filter it and move on.
• If behavior is not locked and cleanup would be risky, stop and lock behavior first.

Expected Output

Return an evidence-dense cleanup report:

• scope
• behavior lock / verification used
• top slop deltas
• feedback kept vs ignored
• simplifications applied
• post-deslop verification
• remaining risks or explicitly deferred cleanup