PluginBench
Skill
Pass
Audit score 90

de-sloppify

codewithmukesh/dotnet-claude-kit

Systematic 7-step .NET code cleanup pipeline with verification between each phase.

What is de-sloppify?

De-sloppify runs an ordered, verified cleanup pipeline over .NET codebases: formatting, unused usings, analyzer warnings, dead code removal, TODO resolution, sealed class audit, and CancellationToken propagation. Use it for pre-release hardening, post-merge cleanup, tech debt sprints, or quarterly maintenance—never mixed with feature work.

  • Formats all code consistently with dotnet format
  • Removes unused using statements via IDE0005 diagnostics
  • Triages and fixes analyzer warnings by category
  • Removes dead code with reflection/DI/serialization safety checks
  • Resolves or files issues for TODO/HACK/FIXME comments
  • Seals non-inherited classes for devirtualization

How to install de-sloppify

npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill de-sloppify
Prerequisites
  • A .NET project with dotnet CLI installed
  • dotnet format and dotnet test working in the project
  • Read references/cleanup-steps.md before executing (safety checklists and per-step details)
Claude Code
Cursor
Windsurf
Cline

How to use de-sloppify

  1. 1.Choose which steps to run based on your scenario (full pass, quick tidy, post-merge, etc.)
  2. 2.Execute steps 1–7 in order; do not skip or reorder
  3. 3.After each step: run dotnet build + dotnet test to verify
  4. 4.Commit each step independently with the provided commit message
  5. 5.If a step breaks the build or tests, fix or revert before continuing to the next step
  6. 6.Review the final report showing changes, files affected, and total commits

Use cases

Good for
  • Pre-release hardening: run all 7 steps before shipping
  • Post-merge cleanup: run steps 1–4 after large feature integrations
  • Dependency upgrade: run steps 2–3 to handle new warnings
  • Performance work: run steps 4 and 6 to remove dead code and seal classes
  • Quick PR tidy: run steps 1, 2, 6 before submitting
Who it's for
  • C# / .NET developers managing code quality
  • Teams with scheduled cleanup sprints or pre-release processes
  • Projects accumulating tech debt or analyzer warnings
  • Performance-focused teams preparing for optimization work

de-sloppify FAQ

Why does order matter?

Formatting touches every file first (get churn out of the way), dead code removal comes late (earlier steps reveal it), and CancellationToken propagation requires understanding the full async chain. Random cleanup misses things and creates merge conflicts.

What if a step breaks the build?

Fix or revert that step before continuing. Never carry a red state into the next step. Each step is its own commit, so a bad Step 4 reverts without losing Steps 1–3.

How do I know if code is truly dead?

The skill checks for reflection, DI-convention registration, and serialization usage that Roslyn cannot see. Read the safety checklist in references/cleanup-steps.md before deleting candidates.

Can I run this during feature work?

No. Cleanup commits must stay pure and separate from feature branches. Run de-sloppify on a dedicated cleanup branch or after merging features.

Which steps should I run for a quick PR tidy?

Steps 1 (format), 2 (unused usings), and 6 (seal classes). For post-merge, add steps 3–4. For dependency upgrades, run steps 2–3 only.

Full instructions (SKILL.md)

Source of truth, from codewithmukesh/dotnet-claude-kit.


name: de-sloppify description: > Systematic code cleanup pipeline for .NET projects. Runs 7 ordered steps: formatting, unused usings, analyzer warnings, dead code removal, TODO resolution, sealed class audit, and CancellationToken propagation. Each step is verified independently with tests between phases. Load this skill when: "clean up", "de-sloppify", "tidy up", "remove dead code", "code cleanup", "housekeeping", "tech debt", "fix warnings", "seal classes", "add CancellationToken", "unused usings", "format code".

/de-sloppify — 7-Step Cleanup Pipeline

What

Runs an ordered, verified cleanup pipeline over a .NET codebase. Order matters: formatting first (it touches every file — get the churn out of the way before anything else), dead code late (earlier steps reveal it). Random cleanup misses things and creates merge conflicts; the pipeline doesn't.

Three rules make it safe:

  1. Verify after each step — dotnet build + dotnet test between steps. A cleanup that breaks something is worse than the mess it was fixing.
  2. Commit per step — each step is its own commit, so a bad Step 4 reverts without losing Steps 1-3.
  3. Safe removals only — before deleting "dead" code, check for reflection, DI-convention, and serialization usage that Roslyn cannot see.

Per-step commands, safety checklists, and code examples live in references/cleanup-steps.md — read it before executing.

When

  • "Clean up", "tidy up", "de-sloppify", "housekeeping", "tech debt"
  • After a large feature merge or dependency upgrade (new warnings accumulate)
  • Pre-release hardening, or a scheduled quarterly cleanup sprint
  • Before performance work (dead code out, classes sealed for devirtualization)
  • Never mixed with feature work — cleanup commits stay pure

How

Step 0: Pick the Steps

ScenarioSteps to run
Full cleanup pass / pre-release / quarterlyAll 7
Quick tidy before PR1, 2, 6
After large feature merge1, 2, 3, 4
After dependency upgrade2, 3
Before performance work4, 6
CI warning threshold exceeded3 only
Tech debt sprint4, 5

Steps 1-7 (execute in order, details in references/cleanup-steps.md)

#StepToolCommit message
1Format all codedotnet formatchore: apply dotnet format
2Remove unused usingsdotnet format analyzers --diagnostics IDE0005chore: remove unused using statements
3Fix analyzer warningsMCP get_diagnostics → triage by categorychore: fix analyzer warnings
4Remove dead codeMCP find_dead_code + safety check (reflection/DI/serialization grep)chore: remove dead code
5Resolve TODOsgrep TODO/HACK/FIXME → fix, file issue, or deletechore: resolve TODO comments
6Seal non-inherited classesMCP get_type_hierarchy per candidate + test-project grepchore: seal non-inherited classes
7Propagate CancellationTokenMCP detect_antipatterns → trace async chainschore: propagate CancellationToken through async chains

After every step: dotnet build + dotnet test, then commit. If a step breaks the build or tests, fix or revert that step before continuing — never carry a red state into the next step. Delegate structural steps (4, 6, 7) to the refactor-cleaner agent.

Final Report

## De-Sloppify Report

| Step | Changes | Files Affected |
|------|---------|----------------|
| 1. Format | Applied consistent formatting | 23 files |
| 2. Usings | Removed 47 unused usings | 18 files |
| 3. Analyzers | Fixed 12 warnings (8 nullability, 3 unused vars, 1 obsolete) | 9 files |
| 4. Dead Code | Removed 3 unused types, 5 unused methods | 6 files |
| 5. TODOs | Fixed 2, created issues for 3, removed 1 stale | 5 files |
| 6. Sealed | Sealed 14 classes | 14 files |
| 7. CancellationToken | Added propagation to 8 async chains | 11 files |

**Total: 7 commits, 86 files improved**

Example

User: /de-sloppify — full pass before the release

Claude: Running the 7-step pipeline...

Step 1: dotnet format — 23 files reformatted. Build + tests green. Committed.
Step 2: IDE0005 — 47 unused usings removed across 18 files. Green. Committed.
Step 3: 12 warnings triaged: 8 nullability fixed with null checks,
  3 unused vars removed, 1 CS0618 migrated off the obsolete API. Committed.
Step 4: find_dead_code → 9 candidates. Safety check: PaymentProcessor is
  registered via DI convention — kept. Removed 3 types, 5 methods. Committed.
Step 5: 6 TODOs → 2 fixed, 3 became issues (#141-#143), 1 stale removed. Committed.
Step 6: 14 classes sealed (2 skipped: xUnit fixture base, virtual members). Committed.
Step 7: 8 async chains now propagate ct end-to-end. Committed.

7 commits, 86 files improved. Full report above.

Related

  • references/cleanup-steps.md — per-step commands, safety checks, examples
  • /verify — run the full verification pipeline after cleanup
  • /health-check — re-grade the project to quantify the improvement
  • /code-review — cleanup handles style; review handles logic and design