agentleFS
codewithmukeshcodewithmukesh/dotnet-claude-kit/skills/de-sloppify/SKILL.md

de-sloppify

Skill808 starsChanged 4 months agoMITView on GitHub

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".

1 other project uses a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After a large feature merge or dependency upgrade (new warnings accumulate)

    line 37
  2. Distinctive:

    Before performance work (dead code out, classes sealed for devirtualization)

    line 39
  3. Distinctive:

    Never mixed with feature work — cleanup commits stay pure

    line 40
  4. Very specific:

    After every step: dotnet build + dotnet test, then commit.

    line 68

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.