用途 Absolute Prune 用于对整个已提交仓库做死代码与依赖清理，典型场景包括：删除死代码、清理未使用的依赖、找出可以删除的内容；移除已无人导入的依赖以减轻打包与安装体积；清理功能改道后留下的孤立文件与导出。它与 simplify 的分工是：simplify 打磨当前工作区的 git diff，prune 则扫描整个已提交仓库、清理全仓库范围内的死代码；simplify 用于改动过程中，prune 用于主分支全绿时的常态清理。
主要能力 它扫描两类问题：一是死依赖，即已声明但从未被导入的依赖，以及被导入但未声明的缺失依赖；二是死代码，即未被引用的导出、不可达分支和孤立文件。工具选择上：JS/TS 使用 depcheck 或 knip（knip 同时覆盖导出与文件），Python 使用 deptry；死代码检测 JS/TS 用 knip、ts-prune、eslint no-unused-vars，Python 用 vulture、ruff 的 unused 规则，Go 用 deadcode ./... 与 staticcheck（U1000），Go 依赖用 go mod tidy（diff）与未使用模块检测。优先使用项目中已有的工具；所有结果只视为候选，删除前需逐一确认不存在动态导入、反射、依赖注入、公共 API 或配置字符串引用。
使用方式 该技能运行 references/health-engine.md 中的共享引擎，遵循 DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT 循环与安全约定，本文件只覆盖 pruning 特有的部分。操作按风险分波次：第 1 波为未使用的 devDeps、未被引用的本地导出/函数，默认立即修复，风险最低；第 2 波为未使用的运行时依赖、孤立的内部文件，需先确认无动态引用再处理；第 3 波为任何可通过公共 API、插件系统、动态 require、反射或配置触达的内容，默认暂缓，高风险误报，需与用户确认或推迟，绝不自动删除。修复按小步、可回滚的波次进行，每波只处理一类（例如先“未使用 devDeps”，再“孤立文件”）；每波之后运行完整的测试、构建与类型检查，构建与类型检查全绿即证明被删符号确实无引用，若出现失败则说明该符号并非死代码，应回滚并重新归类。删除依赖时需从清单中移除、重新生成锁文件并重新构建。生成的代码、vendored 代码、公共 API 表面，以及无法追溯的配置/插件所依赖的内容不应删除，应报告为“疑似死代码，需人工判断”；配置中 preferences.health.protectedPaths 的路径视为永不删除的 glob，匹配项即使在工具标记范围内也不处理。
适用场景与限制 适用于主分支全绿时的常态清理、重构后的孤儿清理和依赖减重；不负责重构线上代码，重构应使用 simplify 或 work。需注意的坑包括：不要盲信工具，动态导入、依赖注入容器、反射和字符串键查找会绕过静态分析，删除前须确认；不要删除库的公共导出，内部未使用的导出可能正是该库的用途，需检查包入口与 exports 映射；不要删除生成或 vendored 文件；不要一次性大清理，否则回归难以二分定位，务必分波次；避免越界进入重构。配套命令有 /absolute simplify（重构 diff 中的线上代码）与 /absolute upgrade（先剪掉未使用依赖，再升级剩余依赖），清理通常也能顺带消除一批 lint 与未使用变量告警。