メニュー
Java Web 死代码清理和重构专家。安全识别并移除死代码，每一步都进行测试验证。 触发条件：用户请求清理死代码、重构优化、移除未使用代码。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | nbl.refactor-clean |
| description | Java Web 死代码清理和重构专家。安全识别并移除死代码，每一步都进行测试验证。 触发条件：用户请求清理死代码、重构优化、移除未使用代码。 |
安全识别并移除死代码，每一步都进行测试验证。
根据项目类型运行分析工具：
| 工具 | 检测内容 | 命令 |
|---|---|---|
| Maven Dependency | 未使用的Maven依赖 | mvn dependency:analyze |
| SpotBugs | 静态代码分析 | mvn spotbugs:check |
| PMD | 代码质量检查+重复代码 | mvn pmd:check |
| JaCoCo | 测试覆盖率分析 | mvn test jacoco:report |
| Checkstyle | 代码规范检查 | mvn checkstyle:check |
如果没有专用工具，使用Grep查找零引用的公开方法：
# 查找类定义，然后检查是否被引用
grep -r "ClassName" --include="*.java" | grep -v "ClassName.java"
将检测结果按安全等级分类：
| 等级 | 示例 | 操作 |
|---|---|---|
| 安全 | 未使用的工具方法、私有方法、常量 | 可放心删除 |
| 谨慎 | Service方法、Controller方法、DTO类 | 验证无动态调用或外部消费者 |
| 危险 | Feign接口、Entity类、枚举类 | 调查后再决定 |
| 禁止 | api模块的公开接口、配置类 | 不允许删除 |
对于每个安全级别的项：
mvn clean test
mvn test
git checkout -- <file> 并跳过此项删除谨慎级别项之前：
Class.forName()、Method.invoke()移除死代码后，检查：
输出结果报告：
死代码清理报告
──────────────────────────────
已删除: 12个未使用方法
3个未使用类
5个未使用依赖
已跳过: 2项（测试失败）
节省: 约450行代码
──────────────────────────────
编译通过 ✅
测试通过 ✅
覆盖率: 85% ✅
删除前验证是否违反分层：
# Controller不能直接调用Mapper
grep -r "Mapper" --include="*Controller.java" | grep -v "//"
# Service层禁止直接使用QueryWrapper
grep -r "QueryWrapper\|LambdaQueryWrapper" --include="*ServiceImpl.java"
# 分析未使用的依赖
mvn dependency:analyze
# 关注输出：
# - Unused declared dependencies: 可安全移除
# - Used undeclared dependencies: 需要显式声明
mvn compile@RequestMapping/@PostMapping/@GetMapping等注解的path值，路径变更须走feature流程Use when executing implementation plans with independent tasks in the current session
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when you have a spec or requirements for a multi-step task, before touching code
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when creating new skills, editing existing skills, or verifying skills work before deployment