|
| 1 | +--- |
| 2 | +description: Run a bounded final deslop pass on a nearly-finished change using slop-scan deltas, focused review lenses, and post-cleanup re-verification |
| 3 | +name: deslop |
| 4 | +metadata: |
| 5 | + skiller: |
| 6 | + source: .agents/rules/deslop.mdc |
| 7 | +--- |
| 8 | + |
| 9 | +# Deslop |
| 10 | + |
| 11 | +Use this after the implementation already works and before commit or push. This |
| 12 | +is not a planning workflow and not a rescue mission for broken code. It is the |
| 13 | +last pressure pass that strips noise out of an otherwise-correct diff. |
| 14 | + |
| 15 | +## Core Contract |
| 16 | + |
| 17 | +- Deslop is a bounded helper inside the normal execution lane, not a competing |
| 18 | + end-to-end workflow. |
| 19 | +- Default scope is changed files only. Do not widen to the whole repo unless |
| 20 | + the user asks. |
| 21 | +- Prefer deleting or inlining over introducing fresh abstraction. |
| 22 | +- Treat slop-scan as signal, not law. Fix the good hits. Ignore the fake ones. |
| 23 | + |
| 24 | +## What Counts As Slop |
| 25 | + |
| 26 | +Focus on concrete smell families, not vague "AI code" vibes: |
| 27 | + |
| 28 | +- needless abstraction: pass-through wrappers, barrel-only indirection, async |
| 29 | + noise, single-use helper layers |
| 30 | +- duplication: repeated signatures, repeated mock setup, local copy-paste |
| 31 | + helpers |
| 32 | +- defensive noise: empty catches, error swallowing, error obscuring where the |
| 33 | + real fix is to rethrow or narrow once |
| 34 | +- structural fragmentation: over-fragmentation and fan-out hotspots when they |
| 35 | + land in the changed area |
| 36 | +- placeholders and leftovers: TODO comments, dead helpers, debug scraps, fake |
| 37 | + scaffolding text |
| 38 | + |
| 39 | +## Inputs To Gather |
| 40 | + |
| 41 | +Before cleanup, collect: |
| 42 | + |
| 43 | +- repo root `AGENTS.md` |
| 44 | +- any nested `AGENTS.md` or design docs that govern the changed area |
| 45 | +- the active plan file when one exists |
| 46 | +- the changed-files list or explicit file scope |
| 47 | +- fresh verification evidence from the implementation pass |
| 48 | +- the repo slop delta command output |
| 49 | + |
| 50 | +## Review Lenses |
| 51 | + |
| 52 | +When the user explicitly asked for deslop / cleanup / refactor, run these 3 |
| 53 | +review lenses in parallel on the same context bundle: |
| 54 | + |
| 55 | +1. Repo rules and documentation conformance |
| 56 | +2. Type safety and source of truth |
| 57 | +3. Simplification and overengineering |
| 58 | + |
| 59 | +If parallel reviewers are unavailable, do the same 3 lenses locally before |
| 60 | +editing. |
| 61 | + |
| 62 | +## Procedure |
| 63 | + |
| 64 | +1. Lock behavior first |
| 65 | + - If current behavior is not already protected, add or run the narrowest |
| 66 | + regression proof before cleanup edits. |
| 67 | + |
| 68 | +2. Bound the scope |
| 69 | + - Build a changed-files list or explicit file scope. |
| 70 | + - Stay inside that scope for both review and cleanup. |
| 71 | + |
| 72 | +3. Launch the review lenses |
| 73 | + - Give every reviewer the same context bundle and one assigned lens. |
| 74 | + - Ask for findings first, ordered by severity, with file references. |
| 75 | + |
| 76 | +4. Run slop delta while reviewers work |
| 77 | + - Prefer the repo script: `bun run lint:slop:delta` |
| 78 | + - If it does not exist, fall back to `slop-scan delta ...` |
| 79 | + - Use delta, not raw repo-wide scan, to focus on added and worsened noise. |
| 80 | + |
| 81 | +5. Synthesize before editing |
| 82 | + - Merge the reviewer output and delta output under: |
| 83 | + - `How did we do?` |
| 84 | + - `Feedback to keep` |
| 85 | + - `Feedback to ignore` |
| 86 | + - `Plan of attack` |
| 87 | + |
| 88 | +6. Apply only the worthwhile fixes |
| 89 | + - type drift, casts, or duplicated type definitions |
| 90 | + - pass-through wrappers, async noise, fake helper seams |
| 91 | + - dead helpers, placeholder comments, debug leftovers |
| 92 | + - duplicate mock setup or local copy-paste helpers |
| 93 | + - empty or error-obscuring internal catches when the right fix is simpler |
| 94 | + |
| 95 | +7. Re-run the narrowest affected verification |
| 96 | + - rerun the same tests, lint, and typecheck lanes that protect the touched |
| 97 | + area |
| 98 | + - if a stronger final gate already existed, rerun it after cleanup |
| 99 | + |
| 100 | +8. Update the story |
| 101 | + - Make sure the active plan, commit text, and PR-facing text describe the |
| 102 | + post-deslop state, not the earlier draft. |
| 103 | + |
| 104 | +## Stop Rules |
| 105 | + |
| 106 | +- Do not widen scope because the scan found juicy unrelated cleanup. |
| 107 | +- Do not start product work during deslop. |
| 108 | +- Do not add abstraction to fix abstraction. |
| 109 | +- If generated, vendored, or fixture noise dominates the scan, filter it and |
| 110 | + move on. |
| 111 | +- If behavior is not locked and cleanup would be risky, stop and lock behavior |
| 112 | + first. |
| 113 | + |
| 114 | +## Expected Output |
| 115 | + |
| 116 | +Return an evidence-dense cleanup report: |
| 117 | + |
| 118 | +- scope |
| 119 | +- behavior lock / verification used |
| 120 | +- top slop deltas |
| 121 | +- feedback kept vs ignored |
| 122 | +- simplifications applied |
| 123 | +- post-deslop verification |
| 124 | +- remaining risks or explicitly deferred cleanup |
0 commit comments