尧图网页设计 
ECC refactor-cleaner 死代码清理 Agent检测工具链、风险分级与分批安全删除流程【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本篇指南基于 ECCEverything Claude Code仓库中的 Kiro Agent 定义文件 refactor-cleaner.md完整拆解该 Agent 的职责边界、工具权限、死代码检测命令、四阶段清理工作流与安全检查清单并结合配套的 refactor-cleaner.json、refactor-clean.md 命令与 quality-gate.sh 质量门禁脚本讲清楚如何在 Kiro 中落地一套检测 → 分级 → 分批删除 → 每批验证的 Agent 化死代码治理方案。1. 定位ECC 中负责 Code Maintenance 的专用 Agent在 ECC 的 Agent 目录中refactor-cleaner被归类为代码维护Code Maintenance方向的专职 Agent负责删除未使用的代码、依赖与重复实现。这一分工在多个地方得到印证AGENTS.md 的 Agent 清单中refactor-cleaner对应 Dead code cleanup分类为 Code maintenancedocs/COMMAND-AGENT-MAP.md 将斜杠命令/refactor-clean与该 Agent 建立了一对一映射Dead code removalREADME.md 的功能表中同样记录了 Remove dead code →/refactor-clean→ refactor-cleaner 这条调用链。ECC 为同一 Agent 维护了三种形态覆盖不同的宿主环境形态文件使用场景MarkdownIDE.kiro/agents/refactor-cleaner.mdKiro IDE 中通过/菜单选择或显式调用JSONCLI.kiro/agents/refactor-cleaner.jsonkiro-cli中通过/agent swap切换Claude Code 变体agents/refactor-cleaner.mdClaude Code 环境下的同名 Agent.kiro/README.md 明确说明.md格式供 IDE 使用自动选择或显式调用.json格式供 CLI 使用/agent swap命令切换两种格式并存是为了最大化兼容且 Agent 实际使用的模型由 Kiro 当前的模型选择决定不由 Agent 配置决定。2. Agent 定义文件职责声明与工具权限2.1 Markdown 定义的 Frontmatterrefactor-cleaner.md 的文件头如下--- name: refactor-cleaner description: Dead code cleanup and consolidation specialist. Use PROACTIVELY for removing unused code, duplicates, and refactoring. Runs analysis tools (knip, depcheck, ts-prune) to identify dead code and safely removes it. allowedTools: - read - write - shell ---allowedTools只开放了read、write、shell三项能力恰好对应该 Agent 工作流的全部动作读代码与运行检测命令read、执行 knip/depcheck/ts-prune 等 CLI 工具shell、删除与合并代码write。没有开放任何网络或 MCP 工具属于最小权限设计。2.2 JSON 变体中的配置字段refactor-cleaner.json 是同一 Agent 的 CLI 配置字段与 MD 变体一一对应可从中读出该 Agent 的完整运行配置allowedTools: [fs_read, fs_write, shell]—— Kiro CLI 对 read/write/shell 的具体工具命名mcpServers: {}、hooks: {}、resources: []—— 不挂载任何 MCP 服务器、钩子或外部资源prompt字段内嵌了与 MD 文件完全一致的完整提示词保证 IDE 与 CLI 两种形态行为一致。从 JSON 结构看ECC 的 Agent 是一个自包含单元描述、权限、提示词全部内聚在单个文件里不依赖外部配置。2.3 Claude Code 变体附加了提示词防御基线对比 agents/refactor-cleaner.md核心提示词与 Kiro 版一致Frontmatter 声明tools: Read, Write, Edit, Bash, Grep, Glob与model: sonnet并在正文最前面附加了一段 Prompt Defense Baseline要求 Agent 不改变角色与身份、不泄露凭据、把外部获取的数据一律视为不可信输入并先行校验。从源码结构看这是 ECC 跨宿主适配时对同一 Agent 做的安全加固层——在允许删除代码的高权限 Agent 上额外约束了输入信任边界。3. 检测工具链四条命令覆盖 JS/TS 项目的死代码盲区Agent 提示词给出的检测命令是npx knip # Unused files, exports, dependencies npx depcheck # Unused npm dependencies npx ts-prune # Unused TypeScript exports npx eslint . --report-unused-disable-directives # Unused eslint directives四条命令分别覆盖四个不同粒度的死代码盲区工具检测对象说明knip未使用的文件、导出、依赖基于入口文件entry points构建完整依赖图能发现整文件无人引用的情况depcheck未使用的 npm 依赖只扫package.json中声明但源码从未 import 的包ts-prune未使用的 TypeScript 导出针对.ts/.tsx模块级导出粒度到单个 export 符号eslint --report-unused-disable-directives失效的 eslint 禁用指令清理历史遗留的eslint-disable注释配套命令 commands/refactor-clean.md 把工具矩阵扩展到了多语言项目可作为同一方法论在其他技术栈上的对照ToolWhat It FindsCommandknipUnused exports, files, dependenciesnpx knipdepcheckUnused npm dependenciesnpx depcheckts-pruneUnused TypeScript exportsnpx ts-prunevultureUnused Python codevulture src/deadcodeUnused Go codedeadcode ./...cargo-udepsUnused Rust dependenciescargo nightly udeps该文档还给出了无检测工具时的降级方案用 Grep 找出所有 export再逐一确认是否被 import。ECC 仓库自身的 package.json 中devDependencies声明了eslint 10.6.0lint脚本为eslint . markdownlint **/*.md --ignore node_modulesengines要求node 18——在以 Node 为主的项目里四条检测命令可以直接通过npx运行无需预先安装。4. 四阶段工作流Analyze → Verify → Remove Safely → Consolidate提示词将清理过程固化为四个阶段这是整个 Agent 方法论的核心。4.1 阶段一 Analyze并行运行检测工具并按风险分级要求并行parallel运行检测工具然后把所有发现按风险分成三级风险等级含义典型对象SAFE可放心删除未使用的导出、未使用的依赖CAREFUL需额外验证通过动态import()加载的模块RISKY原则上不动对外暴露的公共 APIcommands/refactor-clean.md 中的分级表给出了更具体的映射SAFE 包括未使用的工具函数、测试辅助、内部函数CAUTION 包括组件、API 路由、中间件DANGER 包括配置文件、入口文件、类型定义——后两者要求先调查再决定。4.2 阶段二 Verify对每个候选删除项做三重确认对每一个准备删除的项必须完成三项验证Grep 全部引用——包括通过字符串模式出现的动态导入如import(...)、require(...)确认是否属于公共 API——如果该符号从包入口导出删除会破坏外部消费者回看 git 历史——了解该代码当初为何存在避免删掉暂时没人用但属于演进方向的代码。配套命令文档补充了 CAUTION 项的四个具体检查动作搜索import()、require()、__import__等动态加载搜索路由名、配置中的组件名字符串确认是否从公共包 API 导出若是已发布的包检查依赖方dependents。4.3 阶段三 Remove Safely按固定顺序分批删除每批测试加提交删除阶段有三条硬约束只从 SAFE 项开始任何一批都不碰 CAREFUL/RISKY一次只处理一个类别且类别顺序固定deps - exports - files - duplicates依赖 → 导出 → 文件 → 重复代码每批删除后必须跑测试并通过后提交一次 commit。类别顺序的设计值得注意先删依赖只改package.json影响面最小再删导出单文件内符号级修改最后才删整文件和合并重复实现跨文件引用面最大。这是一个由小到大、由浅入深的回滚难度递增序列。commands/refactor-clean.md 把安全删除循环细化成了可操作的五步先跑完整测试套件建立全绿的基线删除死代码用编辑工具做外科手术式的最小改动重跑测试套件验证没有破坏任何东西测试失败则立即回滚git checkout -- file跳过该项测试通过则进入下一项。这保证了任何一次失败删除都能被单步回退而不会污染后续批次。4.4 阶段四 Consolidate Duplicates重复代码合并死代码清理完成后再处理重复实现找出重复的组件/工具函数选择最完整、测试最好的实现作为保留方更新所有 import 指向保留方删除重复实现验证测试通过。配套命令给出了识别重复的量化标准相似度超过 80% 的近似函数应合并冗余类型定义应整合不增值的包装函数应内联无意义的 re-export 应去掉这层间接引用。命令文档还特别强调Dont refactor while cleaning——清理与重构是两件事清理阶段只删不改逻辑避免一次变更混合两种意图。5. 安全检查清单与何时不该用Agent 提示词内嵌了两张可勾选的检查清单分别约束删除前与每批之后Before removing删除前检测工具确认该符号未被使用Grep 确认无引用包括动态引用不属于公共 API删除后测试通过After each batch每批之后构建成功测试通过使用描述性信息完成提交五条关键原则Key Principles进一步收束了行为边界Start small—— 一次只处理一个类别Test often—— 每一批之后都测Be conservative—— 拿不准就不删Document—— 每个批次都写描述性 commit messageNever removeduring active feature development or before deploys —— 活跃特性开发期间和发布前绝不删除。何时不该用清单把这最后一条展开成四个明确的禁入场景正在开发特性时、生产发布前夕、测试覆盖不足时、以及对不理解的代码。配套的 commands/refactor-clean.md 的 Rules 部分同样强调 Never delete without running tests first 与 Skip if uncertain — Better to keep dead code than break production宁可留着死代码也不让生产环境出故障。6. 批次验证的落地机制quality-gate.sh 质量门禁每批之后跑测试在 ECC 的 Kiro 集成里有一个现成的自动化载体.kiro/scripts/quality-gate.sh。该脚本由.kiro/hooks/quality-gate.kiro.hook手动触发执行 build、类型检查、lint、测试四类检查包管理器探测quality-gate.sh#L17-L36依次检查pnpm-lock.yaml、yarn.lock、bun.lockb/bun.lock、package-lock.json兜底按 PATH 中可用的命令判断保证测试命令用项目实际的包管理器运行Buildquality-gate.sh#L57-L63仅当package.json中定义了build脚本时运行否则优雅跳过Type checkquality-gate.sh#L65-L80有tsconfig.json时跑npx tsc --noEmitPython 项目则回退到 pyright/mypyLintquality-gate.sh#L82-L94按 Biome → ESLint → Ruff → golangci-lint 的优先级选择Testsquality-gate.sh#L96-L106优先$PM run test其次pytest、go test ./...。脚本汇总 pass/fail/skip 计数任一失败则输出Quality gate: FAILED并以非零码退出quality-gate.sh#L108-L120。这与提示词每批Build succeeds / Tests pass / Committed的清单项一一对应——在 refactor-cleaner 的批次循环中该脚本就是每批删除后的验证门禁。7. 安装与调用如何在 Kiro 项目中启用该 Agent7.1 安装ECC 的 Kiro 集成通过 .kiro/install.sh 一键安装到任意项目cd .kiro ./install.sh /path/to/your/project # 安装到指定项目 ./install.sh # 安装到当前目录 ./install.sh ~ # 全局安装~/.kiro/安装器是非破坏性复制install.sh#L54-L64 中对每个 agent 文件.json与.md两种格式都复制先检查目标路径是否已存在存在则跳过因此重复安装不会覆盖你的自定义修改。7.2 调用方式按 .kiro/README.md 的说明# CLI以指定 Agent 启动会话 kiro-cli --agent refactor-cleaner Remove unused code and consolidate duplicate functions # CLI会话中切换 /agent swap # 选择 refactor-cleaner # IDE/ 菜单直接调用 /refactor-cleanerREADME 的 Example 9: Refactoring and Cleanup 给出了标准使用节奏先用 refactor-cleaner 识别死代码、发现重复实现、执行安全重构然后紧接/verification-loop做收尾验证build、类型检查、lint、全量测试、安全扫描、diff 审查循环直到全部通过。这与 Agent 提示词每批测试的内建要求形成双层保险。7.3 与 ECC 生态的协作点从仓库引用关系看refactor-cleaner并非孤立存在命令侧commands/refactor-clean.md 提供了多语言扩展版的工作流是同一方法论的命令化表述Agent 侧agents/build-error-resolver.md 的交接规则写明 Code needs refactoring → userefactor-cleaner即构建修错误 Agent 遇到需要重构的代码时会把任务移交过来文档侧docs/COMMAND-AGENT-MAP.md 把/refactor-clean与refactor-cleaner登记为固定映射。可以推断ECC 的设计意图是让清理成为一个可被其他 Agent 明确路由到的专职角色而不是混在通用重构对话里。8. 成功指标如何判断一次清理是成功的提示词给出的验收标准Success Metrics有四条All tests passing—— 测试全绿Build succeeds—— 构建通过No regressions—— 无功能回归Bundle size reduced—— 产物体积下降这是清理工作的直接收益体现。commands/refactor-clean.md 还规定了收尾汇报的固定格式便于把结果沉淀为可审计的记录Dead Code Cleanup ────────────────────────────── Deleted: 12 unused functions 3 unused files 5 unused dependencies Skipped: 2 items (tests failed) Saved: ~450 lines removed ────────────────────────────── All tests passing PASS:注意汇报中显式包含 Skipped 行——因测试失败而被回滚跳过的项目也要如实上报这与 Be conservative 原则互为印证。9. 小结refactor-cleaner的价值不在删代码这个动作本身而在于它为 Agent 化的死代码治理定义了一套可复制的纪律检测工具给出候选 → 风险三级分类限定删除范围 → Grep/公共 API/git 历史三重验证 → 按 deps→exports→files→duplicates 的固定顺序分批删除 → 每批测试加提交、失败立即回滚 → 收尾用验证循环兜底。这套流程全部内聚在 refactor-cleaner.md 这一个文件里配合 quality-gate.sh 的自动化门禁即可在 Kiro 项目中直接落地。对需要把同类方法论移植到其他语言栈的读者commands/refactor-clean.md 中 vulture/deadcode/cargo-udeps 的工具矩阵给出了现成的对照。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ECC refactor-cleaner 死代码清理 Agent：检测工具链、风险分级与分批安全删除流程
ECC refactor-cleaner 死代码清理 Agent检测工具链、风险分级与分批安全删除流程【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本篇指南基于 ECCEverything Claude Code仓库中的 Kiro Agent 定义文件 refactor-cleaner.md完整拆解该 Agent 的职责边界、工具权限、死代码检测命令、四阶段清理工作流与安全检查清单并结合配套的 refactor-cleaner.json、refactor-clean.md 命令与 quality-gate.sh 质量门禁脚本讲清楚如何在 Kiro 中落地一套检测 → 分级 → 分批删除 → 每批验证的 Agent 化死代码治理方案。1. 定位ECC 中负责 Code Maintenance 的专用 Agent在 ECC 的 Agent 目录中refactor-cleaner被归类为代码维护Code Maintenance方向的专职 Agent负责删除未使用的代码、依赖与重复实现。这一分工在多个地方得到印证AGENTS.md 的 Agent 清单中refactor-cleaner对应 Dead code cleanup分类为 Code maintenancedocs/COMMAND-AGENT-MAP.md 将斜杠命令/refactor-clean与该 Agent 建立了一对一映射Dead code removalREADME.md 的功能表中同样记录了 Remove dead code →/refactor-clean→ refactor-cleaner 这条调用链。ECC 为同一 Agent 维护了三种形态覆盖不同的宿主环境形态文件使用场景MarkdownIDE.kiro/agents/refactor-cleaner.mdKiro IDE 中通过/菜单选择或显式调用JSONCLI.kiro/agents/refactor-cleaner.jsonkiro-cli中通过/agent swap切换Claude Code 变体agents/refactor-cleaner.mdClaude Code 环境下的同名 Agent.kiro/README.md 明确说明.md格式供 IDE 使用自动选择或显式调用.json格式供 CLI 使用/agent swap命令切换两种格式并存是为了最大化兼容且 Agent 实际使用的模型由 Kiro 当前的模型选择决定不由 Agent 配置决定。2. Agent 定义文件职责声明与工具权限2.1 Markdown 定义的 Frontmatterrefactor-cleaner.md 的文件头如下--- name: refactor-cleaner description: Dead code cleanup and consolidation specialist. Use PROACTIVELY for removing unused code, duplicates, and refactoring. Runs analysis tools (knip, depcheck, ts-prune) to identify dead code and safely removes it. allowedTools: - read - write - shell ---allowedTools只开放了read、write、shell三项能力恰好对应该 Agent 工作流的全部动作读代码与运行检测命令read、执行 knip/depcheck/ts-prune 等 CLI 工具shell、删除与合并代码write。没有开放任何网络或 MCP 工具属于最小权限设计。2.2 JSON 变体中的配置字段refactor-cleaner.json 是同一 Agent 的 CLI 配置字段与 MD 变体一一对应可从中读出该 Agent 的完整运行配置allowedTools: [fs_read, fs_write, shell]—— Kiro CLI 对 read/write/shell 的具体工具命名mcpServers: {}、hooks: {}、resources: []—— 不挂载任何 MCP 服务器、钩子或外部资源prompt字段内嵌了与 MD 文件完全一致的完整提示词保证 IDE 与 CLI 两种形态行为一致。从 JSON 结构看ECC 的 Agent 是一个自包含单元描述、权限、提示词全部内聚在单个文件里不依赖外部配置。2.3 Claude Code 变体附加了提示词防御基线对比 agents/refactor-cleaner.md核心提示词与 Kiro 版一致Frontmatter 声明tools: Read, Write, Edit, Bash, Grep, Glob与model: sonnet并在正文最前面附加了一段 Prompt Defense Baseline要求 Agent 不改变角色与身份、不泄露凭据、把外部获取的数据一律视为不可信输入并先行校验。从源码结构看这是 ECC 跨宿主适配时对同一 Agent 做的安全加固层——在允许删除代码的高权限 Agent 上额外约束了输入信任边界。3. 检测工具链四条命令覆盖 JS/TS 项目的死代码盲区Agent 提示词给出的检测命令是npx knip # Unused files, exports, dependencies npx depcheck # Unused npm dependencies npx ts-prune # Unused TypeScript exports npx eslint . --report-unused-disable-directives # Unused eslint directives四条命令分别覆盖四个不同粒度的死代码盲区工具检测对象说明knip未使用的文件、导出、依赖基于入口文件entry points构建完整依赖图能发现整文件无人引用的情况depcheck未使用的 npm 依赖只扫package.json中声明但源码从未 import 的包ts-prune未使用的 TypeScript 导出针对.ts/.tsx模块级导出粒度到单个 export 符号eslint --report-unused-disable-directives失效的 eslint 禁用指令清理历史遗留的eslint-disable注释配套命令 commands/refactor-clean.md 把工具矩阵扩展到了多语言项目可作为同一方法论在其他技术栈上的对照ToolWhat It FindsCommandknipUnused exports, files, dependenciesnpx knipdepcheckUnused npm dependenciesnpx depcheckts-pruneUnused TypeScript exportsnpx ts-prunevultureUnused Python codevulture src/deadcodeUnused Go codedeadcode ./...cargo-udepsUnused Rust dependenciescargo nightly udeps该文档还给出了无检测工具时的降级方案用 Grep 找出所有 export再逐一确认是否被 import。ECC 仓库自身的 package.json 中devDependencies声明了eslint 10.6.0lint脚本为eslint . markdownlint **/*.md --ignore node_modulesengines要求node 18——在以 Node 为主的项目里四条检测命令可以直接通过npx运行无需预先安装。4. 四阶段工作流Analyze → Verify → Remove Safely → Consolidate提示词将清理过程固化为四个阶段这是整个 Agent 方法论的核心。4.1 阶段一 Analyze并行运行检测工具并按风险分级要求并行parallel运行检测工具然后把所有发现按风险分成三级风险等级含义典型对象SAFE可放心删除未使用的导出、未使用的依赖CAREFUL需额外验证通过动态import()加载的模块RISKY原则上不动对外暴露的公共 APIcommands/refactor-clean.md 中的分级表给出了更具体的映射SAFE 包括未使用的工具函数、测试辅助、内部函数CAUTION 包括组件、API 路由、中间件DANGER 包括配置文件、入口文件、类型定义——后两者要求先调查再决定。4.2 阶段二 Verify对每个候选删除项做三重确认对每一个准备删除的项必须完成三项验证Grep 全部引用——包括通过字符串模式出现的动态导入如import(...)、require(...)确认是否属于公共 API——如果该符号从包入口导出删除会破坏外部消费者回看 git 历史——了解该代码当初为何存在避免删掉暂时没人用但属于演进方向的代码。配套命令文档补充了 CAUTION 项的四个具体检查动作搜索import()、require()、__import__等动态加载搜索路由名、配置中的组件名字符串确认是否从公共包 API 导出若是已发布的包检查依赖方dependents。4.3 阶段三 Remove Safely按固定顺序分批删除每批测试加提交删除阶段有三条硬约束只从 SAFE 项开始任何一批都不碰 CAREFUL/RISKY一次只处理一个类别且类别顺序固定deps - exports - files - duplicates依赖 → 导出 → 文件 → 重复代码每批删除后必须跑测试并通过后提交一次 commit。类别顺序的设计值得注意先删依赖只改package.json影响面最小再删导出单文件内符号级修改最后才删整文件和合并重复实现跨文件引用面最大。这是一个由小到大、由浅入深的回滚难度递增序列。commands/refactor-clean.md 把安全删除循环细化成了可操作的五步先跑完整测试套件建立全绿的基线删除死代码用编辑工具做外科手术式的最小改动重跑测试套件验证没有破坏任何东西测试失败则立即回滚git checkout -- file跳过该项测试通过则进入下一项。这保证了任何一次失败删除都能被单步回退而不会污染后续批次。4.4 阶段四 Consolidate Duplicates重复代码合并死代码清理完成后再处理重复实现找出重复的组件/工具函数选择最完整、测试最好的实现作为保留方更新所有 import 指向保留方删除重复实现验证测试通过。配套命令给出了识别重复的量化标准相似度超过 80% 的近似函数应合并冗余类型定义应整合不增值的包装函数应内联无意义的 re-export 应去掉这层间接引用。命令文档还特别强调Dont refactor while cleaning——清理与重构是两件事清理阶段只删不改逻辑避免一次变更混合两种意图。5. 安全检查清单与何时不该用Agent 提示词内嵌了两张可勾选的检查清单分别约束删除前与每批之后Before removing删除前检测工具确认该符号未被使用Grep 确认无引用包括动态引用不属于公共 API删除后测试通过After each batch每批之后构建成功测试通过使用描述性信息完成提交五条关键原则Key Principles进一步收束了行为边界Start small—— 一次只处理一个类别Test often—— 每一批之后都测Be conservative—— 拿不准就不删Document—— 每个批次都写描述性 commit messageNever removeduring active feature development or before deploys —— 活跃特性开发期间和发布前绝不删除。何时不该用清单把这最后一条展开成四个明确的禁入场景正在开发特性时、生产发布前夕、测试覆盖不足时、以及对不理解的代码。配套的 commands/refactor-clean.md 的 Rules 部分同样强调 Never delete without running tests first 与 Skip if uncertain — Better to keep dead code than break production宁可留着死代码也不让生产环境出故障。6. 批次验证的落地机制quality-gate.sh 质量门禁每批之后跑测试在 ECC 的 Kiro 集成里有一个现成的自动化载体.kiro/scripts/quality-gate.sh。该脚本由.kiro/hooks/quality-gate.kiro.hook手动触发执行 build、类型检查、lint、测试四类检查包管理器探测quality-gate.sh#L17-L36依次检查pnpm-lock.yaml、yarn.lock、bun.lockb/bun.lock、package-lock.json兜底按 PATH 中可用的命令判断保证测试命令用项目实际的包管理器运行Buildquality-gate.sh#L57-L63仅当package.json中定义了build脚本时运行否则优雅跳过Type checkquality-gate.sh#L65-L80有tsconfig.json时跑npx tsc --noEmitPython 项目则回退到 pyright/mypyLintquality-gate.sh#L82-L94按 Biome → ESLint → Ruff → golangci-lint 的优先级选择Testsquality-gate.sh#L96-L106优先$PM run test其次pytest、go test ./...。脚本汇总 pass/fail/skip 计数任一失败则输出Quality gate: FAILED并以非零码退出quality-gate.sh#L108-L120。这与提示词每批Build succeeds / Tests pass / Committed的清单项一一对应——在 refactor-cleaner 的批次循环中该脚本就是每批删除后的验证门禁。7. 安装与调用如何在 Kiro 项目中启用该 Agent7.1 安装ECC 的 Kiro 集成通过 .kiro/install.sh 一键安装到任意项目cd .kiro ./install.sh /path/to/your/project # 安装到指定项目 ./install.sh # 安装到当前目录 ./install.sh ~ # 全局安装~/.kiro/安装器是非破坏性复制install.sh#L54-L64 中对每个 agent 文件.json与.md两种格式都复制先检查目标路径是否已存在存在则跳过因此重复安装不会覆盖你的自定义修改。7.2 调用方式按 .kiro/README.md 的说明# CLI以指定 Agent 启动会话 kiro-cli --agent refactor-cleaner Remove unused code and consolidate duplicate functions # CLI会话中切换 /agent swap # 选择 refactor-cleaner # IDE/ 菜单直接调用 /refactor-cleanerREADME 的 Example 9: Refactoring and Cleanup 给出了标准使用节奏先用 refactor-cleaner 识别死代码、发现重复实现、执行安全重构然后紧接/verification-loop做收尾验证build、类型检查、lint、全量测试、安全扫描、diff 审查循环直到全部通过。这与 Agent 提示词每批测试的内建要求形成双层保险。7.3 与 ECC 生态的协作点从仓库引用关系看refactor-cleaner并非孤立存在命令侧commands/refactor-clean.md 提供了多语言扩展版的工作流是同一方法论的命令化表述Agent 侧agents/build-error-resolver.md 的交接规则写明 Code needs refactoring → userefactor-cleaner即构建修错误 Agent 遇到需要重构的代码时会把任务移交过来文档侧docs/COMMAND-AGENT-MAP.md 把/refactor-clean与refactor-cleaner登记为固定映射。可以推断ECC 的设计意图是让清理成为一个可被其他 Agent 明确路由到的专职角色而不是混在通用重构对话里。8. 成功指标如何判断一次清理是成功的提示词给出的验收标准Success Metrics有四条All tests passing—— 测试全绿Build succeeds—— 构建通过No regressions—— 无功能回归Bundle size reduced—— 产物体积下降这是清理工作的直接收益体现。commands/refactor-clean.md 还规定了收尾汇报的固定格式便于把结果沉淀为可审计的记录Dead Code Cleanup ────────────────────────────── Deleted: 12 unused functions 3 unused files 5 unused dependencies Skipped: 2 items (tests failed) Saved: ~450 lines removed ────────────────────────────── All tests passing PASS:注意汇报中显式包含 Skipped 行——因测试失败而被回滚跳过的项目也要如实上报这与 Be conservative 原则互为印证。9. 小结refactor-cleaner的价值不在删代码这个动作本身而在于它为 Agent 化的死代码治理定义了一套可复制的纪律检测工具给出候选 → 风险三级分类限定删除范围 → Grep/公共 API/git 历史三重验证 → 按 deps→exports→files→duplicates 的固定顺序分批删除 → 每批测试加提交、失败立即回滚 → 收尾用验证循环兜底。这套流程全部内聚在 refactor-cleaner.md 这一个文件里配合 quality-gate.sh 的自动化门禁即可在 Kiro 项目中直接落地。对需要把同类方法论移植到其他语言栈的读者commands/refactor-clean.md 中 vulture/deadcode/cargo-udeps 的工具矩阵给出了现成的对照。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考