关于 de-sloppify
de-sloppify 是面向 .NET 代码库的有序清理技能,按步骤执行并逐步验证。它通过每步构建、测试和单独提交,帮助开发者将维护工作与功能开发分开。
主要功能
- 01七步 .NET 清理流程
- 02按场景选择执行步骤
- 03每步后构建和测试
- 04每步单独提交
- 05删除死代码前进行安全检查
- 06生成最终清理报告
适用场景
- 01准备 .NET 项目发布
- 02大型合并后整理代码库
- 03依赖升级后处理警告
- 04开展定期技术债清理
MCP 相关
该流程在特定步骤中使用 get_diagnostics、find_dead_code、get_type_hierarchy 和 detect_antipatterns 等 MCP 工具。
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ codewithmukesh/ dotnet-claude-kit --skill de-sloppify安装后在 Claude Code 中输入/de-sloppify确认已加载。
附带文件references/cleanup-steps.md
详细介绍
/de-sloppify — 7 步清理流程
内容
在 .NET 代码库中按顺序运行经过验证的清理流程。顺序很重要: 先格式化(它会触及每个文件——先处理这些变更,再做其他事情),最后处理死代码(前面的步骤会将其暴露出来)。随意清理会遗漏问题并造成合并冲突;此流程不会。
三条规则确保流程安全:
- 每一步之后都要验证——在各步骤之间运行
dotnet build+dotnet test。清理如果导致问题,比它要解决的混乱更糟。 - 每一步单独提交——每一步都有自己的提交,因此如果第 4 步出错,可以回滚而不丢失第 1 至第 3 步的成果。
- 只进行安全删除——删除“死”代码前,检查 Roslyn 无法检测到的反射、DI 约定和序列化用法。
每一步的命令、安全检查清单和代码示例都在
references/cleanup-steps.md 中——执行前请先阅读。
适用场景
- “清理一下”“整理一下”“去除杂乱”“维护工作”“技术债务”
- 大型功能合并或依赖升级之后(会累积新的警告)
- 发布前加固,或按季度安排的清理冲刺
- 性能优化之前(移除死代码,为去虚拟化密封类)
- 切勿与功能开发混在一起——清理提交应保持纯粹
用法
步骤 0:选择要执行的步骤
| 场景 | 要执行的步骤 |
|---|---|
| 全面清理 / 发布前 / 季度清理 | 全部 7 步 |
| PR 前快速整理 | 1、2、6 |
| 大型功能合并之后 | 1、2、3、4 |
| 依赖升级之后 | 2、3 |
| 性能优化之前 | 4、6 |
| CI 警告阈值超限 | 仅第 3 步 |
| 技术债务冲刺 | 4、5 |
步骤 1-7(按顺序执行,详情见 references/cleanup-steps.md)
| # | 步骤 | 工具 | 提交消息 |
|---|---|---|---|
| 1 | 格式化所有代码 | dotnet format | chore: apply dotnet format |
| 2 | 移除未使用的 using 指令 | dotnet format analyzers --diagnostics IDE0005 | chore: remove unused using statements |
| 3 | 修复分析器警告 | MCP get_diagnostics → 按类别分类处理 | chore: fix analyzer warnings |
| 4 | 移除死代码 | MCP find_dead_code + 安全检查(搜索反射/DI/序列化用法) | chore: remove dead code |
| 5 | 处理 TODO | 搜索 TODO/HACK/FIXME → 修复、创建问题单或删除 | chore: resolve TODO comments |
| 6 | 密封未被继承的类 | 对每个候选类使用 MCP get_type_hierarchy + 搜索测试项目 | chore: seal non-inherited classes |
| 7 | 传递 CancellationToken | MCP detect_antipatterns → 跟踪异步调用链 | chore: propagate CancellationToken through async chains |
每一步之后:运行 dotnet build + dotnet test,然后提交。如果某一步导致构建或测试失败,继续之前先修复或回滚该步骤——绝不要将失败状态带入下一步。将结构性步骤(4、6、7)委派给
refactor-cleaner Agent。
最终报告
## 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**
示例
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.
相关内容
references/cleanup-steps.md— 每一步的命令、安全检查和示例/verify— 清理后运行完整验证流程/health-check— 重新评估项目,量化改进效果/code-review— 清理负责风格;审查负责逻辑和设计
评论
支持 Markdown