prune

用途

prune 面向的是“经过 5–15 轮 AI 迭代编码之后”的代码库。此时功能可能已经可用、测试也可能通过，但工作区 diff 中会积累大量 AI 残留：早期提示词留下的孤立辅助函数、死类型、半迁移状态、投机性配置键以及僵尸工作流。prune 的作用是充当“证据式垃圾回收器”和架构协调器，审计并剥离这些残留、死代码和 YAGNI 膨胀。

核心哲学：倒置举证责任

常规编码中开发者往往默认“AI 写了它，所以大概需要”。prune 完全反转这一假设：审计 diff 中每个新增或修改的函数、类型、参数、状态钩子、包装器和导出都被假定为有罪（死代码、意外残留或 YAGNI 膨胀），直到用具体证据证明其清白。若某个符号无法提供可达性和具体必要性的证明，就会被列入删除队列。

四项证据检验

要让符号在裁剪中存活，必须通过以下四项测试：

可达性证明：运行时执行能否真正到达这里？需要从活跃入口点（路由、UI 组件、CLI 命令、导出或事件处理器）追踪出直接调用链。失败则视为死代码/僵尸代码，予以清除。
需求证明：哪条明确的用户需求要求了它？需要指出要求该分支或参数的具体用户故事或缺陷修复。如果答案是“以后可能会用到”，则失败。失败则视为 YAGNI 膨胀，予以剥离。
非重复证明：这段逻辑在代码库中是否已经存在？需要核实是否已有辅助函数、工具或标准库方法处理了它。失败则视为意外重复造轮子，予以合并。
破坏性证明：如果现在删除它，哪个测试或行为会失败？需要模拟删除或检查测试覆盖。如果没有任何失败、也没有行为变化，那它为什么存在？失败则视为幽灵脚手架，予以移除。

工作流程

流程为：询问范围 → 构建调用图并运行四项证明 → 向用户呈现证据表 → 请求批准 → 裁剪并验证（测试通过）。

第 1 步：提示范围。 绝不假设 diff 目标，立即用 ask_question 让用户选择审计边界：未提交工作区（已暂存 + 未暂存 git diff，推荐）、当前分支对比基线（git diff origin/main...HEAD 或 main...HEAD）、最近 N 个提交（如 HEAD~3..HEAD）、或特定文件/目录（自定义路径）。如果用户在初始提示中已给出具体目标（如 prune HEAD~2..HEAD 或 prune src/auth/），则直接确认该目标。

第 2 步：用证据证明审计 diff。 检查所选范围内每个新增或修改的文件，提取所有新增/修改符号（函数、方法、类；类型、接口、DTO、枚举；导入和导出变量；状态变量、props、hooks、事件处理器；参数、标志、配置键），追踪调用图（从叶子辅助函数向上追踪调用者；注意僵尸链——即使 WorkflowA 调用了某辅助函数，若 WorkflowA 本身从应用入口点没有任何调用者，该辅助函数也不算存活），并将发现分类为四个层级：

🟢 第 1 层：无争议的死残留（零风险）——零引用局部函数、未使用导入、孤立类型、不可达 if/else 分支、死测试夹具。
🟡 第 2 层：僵尸工作流与废弃迭代（中风险）——第 2 轮创建、第 6 轮改变方案后被放弃但仍连接到幽灵状态的处理器或多步逻辑。
🟠 第 3 层：投机性 / YAGNI 膨胀（设计层面）——未使用的选项、只有一个琐碎调用者的防御性包装器、过度泛化的辅助参数。
🔵 第 4 层：意外重复——迭代期间编写的、重新发明了现有代码库工具的自定义辅助函数。

第 3 步：呈现发现。 在改动任何代码之前，输出结构化的“证据与裁剪表”，包含层级、文件、符号/代码块、未通过的证明与证据、建议操作。例如：某函数可达性为 0 个调用点则删除；某类型无引用则删除；某处理器被后续方案取代且只被未使用的草稿处理器调用则删除处理器与状态；某配置项在所有地方都硬编码为默认值、无调用者提供自定义延迟则内联并简化。

第 4 步：请求明确批准。 绝不在没有人工签字的情况下裁剪。用 ask_question 请求用户裁决：裁剪所有已验证项（第 1、2、3、4 层，推荐）、仅裁剪第 1 层（零风险死代码与无引用符号）、由用户指定保留或裁剪哪些项、或取消（保持工作区不变）。若用户选择第三项，需先询问要保留表中的哪些具体项。

第 5 步：外科式裁剪与验证。 批准后：删除已批准的函数、类型、分支和参数；清理删除后遗留的未使用导入和多余变量；遵循 smart-comments 原则——保留承载关键信息的“地雷/WHY”注释，仅当注释所解释的代码已被删除时才移除注释；运行验证（测试套件如 npm test、pytest、cargo test、go test 等，以及类型检查如 tsc、mypy、cargo check 等或构建命令）；若测试失败，检查是测试在测试已删除的死路径（更新测试）还是触及了非预期依赖（回滚并修复）；最后总结结果，包括删除的代码行数、清理的文件数、最终验证/测试状态（如全部 42 个测试通过）。

与同类技能的关系

8020：编码前使用，选择最小可用路径，从一开始避免构建膨胀。
pre-plan：编码前使用，在生成代码前对齐设计概念。
distill-need：编码前使用，判断任务是否真的需要构建。
smart-comments：编码/裁剪期间使用，保留承载关键信息的 WHY 注释，避免嘈杂的 WHAT 注释。
prune：编码/迭代之后使用，审计并剥离跨 AI 提示词积累的残留、死代码和投机性膨胀。
reviewer-clone：PR 审查时使用，通过个人审查视角审查最终干净的 PR。

使用准则

应当：在运行分析前用 ask_question 提示审计范围；为每个标记项提供具体证据（如“仓库中 0 个引用”“唯一调用者是死函数 X”）；在删除文件或代码块前通过 ask_question 要求用户明确批准；裁剪后立即运行测试和类型检查以证明构建仍然通过。不应：未经确认就猜测 git diff 目标；在没有展示调用图证据的情况下说“这看起来不必要”；在后台静默删除代码；清理后留下损坏的导入或失败的测试套件。

限制

资料未提供该技能的具体安装命令、支持的平台、收费或价格信息，这些事实暂未提供。