用途：识别代码库中的死代码。核心规则是仅被测试引用的代码仍算死代码，只有生产环境使用才算存活；对于未完成实现中已声明但未使用的符号，若 git 历史显示其属于未完成栈的一部分，建议调查而非删除。
主要能力与流程：
- 检测语言、范围与测试边界：检查 package.json、tsconfig.json、pyproject.toml、Cargo.toml、go.mod 等配置文件，按顶层源码目录划分分析单元，并依据各语言测试文件模式（如 .test.ts、test_.py、*_test.go、tests/** 等）区分测试与生产引用。
- 可选 CLI 快速扫描：TS/JS 用 npx knip --no-exit-code，Python 用 vulture <src_dirs> --min-confidence 80，Swift 用 periphery scan --skip-build，Go 用 deadcode ./...，Rust 用 cargo build 2>&1 | grep "dead_code"。注意 CLI 会把测试导入计为真实使用，无法检测仅测试引用，需依赖后续分析。
- 并行子代理分析（核心）：每个顶层源码目录一个子代理，使用 opus 模型，最多 8 个；子代理在隔离的 git worktree 中只读操作，不切换 HEAD，用 git show <ref>:<path> 读取其他引用，独立安装依赖，测试运行器置于独立进程组并加超时，结束后验证 worktree 已移除、git status --short 干净、HEAD 未变、依赖目录仍可解析，并报告无法停止的进程 PID。
- 合并与过滤：去重，跳过框架入口点、再导出链、动态用法、跨包引用，并交叉核对设计文档/路线图/TODO，将仅测试引用但出现在计划中的标记为 investigate。
- 评估与建议：运行 /evaluate-findings 验证，按信号给出 delete 或 investigate；对 investigate 运行 /investigate。
常见模式：仅测试的状态访问器、未使用的数据模型字段、残留枚举分支、孤立的便捷方法。
限制：CLI 工具无法检测仅测试引用；动态用法、框架约定、复杂再导出链可能导致误判；超过 8 个顶层目录需用户缩小范围；未发现死代码时需明确报告并说明范围限制。