trash-truck

Trash Truck

质疑某个表面是否应该继续存在。优先删除，而不是简化；优先简化，而不是优化；优先优化，而不是自动化。有充分依据地得出 keep、insufficient evidence 或不做更改的结果，也算完成工作。

调用

/trash-truck OWNER/REPO mode:interactive
/trash-truck OWNER/REPO mode:interactive candidate:"<description>"
/trash-truck OWNER/REPO mode:scheduled
/trash-truck OWNER/REPO mode:scheduled persist:github

OWNER/REPO 为必填项。candidate:"<description>" 为可选项，且仅在交互模式下有效。请将完整描述括在引号内；不要将后续的自由文本视为候选项的一部分。persist:github 为可选项，且仅在计划模式下有效；它必须来自所有者配置的计划，或所有者当前的明确请求。如果这些组合无效，或者模式缺失或未知，请以输入错误停止。

调查前先确定模式：

情况	模式	允许的结果
有用户在场，且明确指定了 mode:interactive	交互式发现或指定目标审查	提出建议；仅对符合条件的 retire 或 prune/simplify 候选项提供选择；最多执行一个已批准的清单
计划或自动化调用此技能，且未指定 persist:github	计划模式	调查，报告 issue_persistence: not-requested，然后停止
所有者授权的计划调用 mode:scheduled persist:github	带持久化的计划模式	调查，有条件地创建一个规范审查议题，然后停止
无法确定交互式所有者是否在场（由调用 Agent 判断，而非机械检查）	计划模式安全兜底	仅报告；绝不修改产品或仓库状态

规范化解析后的输入，并在继续前运行 python3 <skill-dir>/scripts/rank_candidates.py mode <invocation-json>。验证器报错时停止。

不可逾越的边界

• 计划模式绝不编辑代码、删除内容、打开退役 PR、禁用作业、变更架构或数据、修改基础设施、合并、部署或同步在线技能。
• 在所有者选择向其展示的确切候选指纹和退役清单之前，交互式调查只读。
• 选择不等于笼统的删除授权。架构、数据、基础设施、外部集成、合并、部署及其他需要所有者把关的操作，仍须分别获得明确授权。
• GitHub 议题、过往意见、过期批准或候选评分都是证据，不是执行授权。
• 绝不将不可用、失败、过时或环境错误的遥测数据解读为零使用量。
• 结果不得凑数。最多返回三个候选项。
• resolve_mode() 不会判断所有者是否在场——它只验证传入的 mode/candidate/ persist 字符串。“交互式所有者是否在场不明确”这一安全兜底，是调用 Agent 必须自行判断并遵守的指示，而非机械检查。实际存在补偿性控制：执行还要求所有者明确选择 确切的候选指纹（参见刷新与失效），调度器无法伪造这一选择。

工作流

1. 预检仓库与授权

1. 阅读目标仓库的现行指示、议题提交政策和破坏性操作规则。
2. 确认仓库身份、当前修订版本、默认分支、脏状态以及可用的只读证据能力。
3. 在计划模式下，除非明确指定 persist:github，否则将持久化视为未请求。若已明确指定，则分别核实所有者配置的授权、仓库政策、凭据范围，以及仓库范围内的序列化机制或原子锁。
4. 不要在命令、工作者简报、证据包或议题内容中泄露机密。

如果无法识别仓库，或请求范围违反仓库政策，请以阻碍项停止。 如果指定的候选项可能指向多个概念上的表面，请先让所有者明确界定范围，再生成指纹或收集证据。

2. 界定调查范围

从指定的仓库开始。仅追踪其配置、部署清单、运行时标识符或权威文档所标明的直接运行依赖，例如：

• 已部署的服务和修订版本；
• 作业、计划任务、队列和工作进程；
• 由该表面直接拥有的数据库、存储桶、主题和基础设施；
• 由该表面发出或接收的分析事件、日志、集成和外部回调；
• 直接引用的仓库或软件包。

不要扩展到供应商的整个账户、无关仓库或传递依赖。如果存在 candidate:<description>，只调查该目标；将无关发现记录为范围外，不要将其提名。

3. 收集证据并尝试证伪退役

收集证据前，请阅读 references/candidate-packet.md。

使用实际存在的证据来源。当执行环境支持时，优先安排独立的只读工作进程分别调查可分离的来源：

来源	有用的证据
代码和依赖项	引用、导入、路由、功能标志、生成的客户端、动态查找、测试、配置
GitHub 和 git	未解决和已关闭的问题、已合并和已放弃的 PR、提交、blame、代码所有者、弃用决策、后续工作
运行时	已部署的修订版本、服务清单、流量、调用日志、错误、队列或作业活动
产品分析	PostHog、Mixpanel 或同类工具中的事件和漏斗数据，包含身份、分母、环境和足够长的时间窗口
运维	CloudWatch 或同类工具的日志、计划任务、警报、操作手册、基础设施状态、集成投递记录
人员和所有权	已知使用方、所有者确认、支持或合规义务、特殊或季节性使用情况

每个工作进程接收一个范围明确的只读问题，并返回证据包。工作进程不得为候选项排序、修改状态或决定是否退役。由一名整理者核对身份、环境、矛盾、时效性和复现周期。

对每条线索，都要主动查找反证。仅凭代码中没有引用不足以得出结论。区分被动安装或加载与实际调用。已核实的实际使用会阻止退役所涉及的范围，但可以支持保留该使用并简化范围更小的部分。

4. 整理候选项证据包并排序

按照 references/candidate-packet.md 中的资格、重要性、评分、平局处理和审批规则执行。按其中的说明规范化有相互印证的线索，然后在捆绑的验证器可用时运行 python3 <skill-dir>/scripts/rank_candidates.py rank <candidate-json>。如果无法运行，请手动应用相同的评分标准，并说明排序未经机械验证。

发现阶段应对所有符合资格的候选项排序，并仅列出排名最高的零至三个。对于指定目标，不要列出备选项；返回以下其中一项：

• retire — 证据支持移除完整声明范围；
• prune/simplify — 该表面的部分内容仍有必要保留；
• keep — 已核实的使用或义务不支持退役；
• insufficient evidence — 证据不足以支持安全决策。

每个符合资格的 retire 或 prune/simplify 候选项都必须包含其指纹、各项评分、支持和反对退役的证据、尚未解决的缺口、已知所有者和使用方、最后一次已核实使用时间、退役清单、排除项、可逆性以及所有者审批关卡。keep 或 insufficient evidence 评估应包含指纹、决定性证据、来源覆盖情况、已知所有者和使用方以及缺口，但不包含退役评分或可执行清单。

5. 按模式分支

定时执行

阅读 references/canonical-issue.md。规范化预检结果，并运行 python3 <skill-dir>/scripts/rank_candidates.py persistence <persistence-json>。如果没有 persist:github，则报告 not-requested 并停止。仅当确定性决策要求执行时，才执行返回的 create 或 update；否则报告其 not-needed 或 blocked 结果并停止。

1. 最多汇总到一个规范的退役审查 issue。
2. 仅记录发生实质性变化的调查。
3. 重新读取已存储的 issue 或评论，并验证标记和内容。
4. 将持久化状态报告为 verified、not-requested、not-needed、blocked 或 failed。
5. 停止。

没有任何候选项（包括高置信度候选项）可以作为定时执行的依据。

交互式发现

如果排名结果为空，则报告无变化并停止，不要要求选择。否则，展示排名后的候选项信息包，请负责人选择一个确切的指纹或停止，然后停止并等待。

交互式指定目标

对于 retire 或 prune/simplify，展示判定结果和确切清单，请求负责人针对该指纹和范围确认执行或不执行，然后停止并等待。对于 keep 或 insufficient evidence，展示评估结果并停止，不提供执行选项。

6. 执行前刷新

选择后，刷新所有实质性支撑资格判定或评分、且可能发生变化的来源。仍然新鲜的稳定证据可继续使用。针对已展示并刷新的候选项运行 python3 <skill-dir>/scripts/rank_candidates.py approval <approval-json>。如果验证器不可用、报错或返回 valid: false，则不要执行。

发生以下任一情况时，作废该选择并重新展示候选项：

• 出现了经核实的正向使用；
• 目标或已部署版本发生实质性变化；
• 置信度低于资格门槛；
• 用于支持退役决定的来源已过时、失败或环境不匹配；
• 退役清单或不可逆影响范围扩大；
• 发现了新的负责人门槛。

刷新后的结果可能是 keep、insufficient evidence 或无变化。

7. 执行一个已批准的范围

最多执行一个选定的候选项。遵循目标仓库的常规实现、测试、审查和交付工作流。

在所有纳入范围的环节中，完整移除已授权的范围：代码、测试、文档、配置、作业、集成、架构、数据和基础设施。不得触及排除在外或另行设有门槛的环节。如果无法安全地完整退役，但获批的较小简化确有价值，应优先选择简化，而不是优化或自动化。

编辑前，记录干净的基线，以及用于保护范围外行为的特征描述或使用证据。编辑后，验证：

• 静态使用方和动态入口点不再依赖已退役的环节；
• 有意义的检查应按照所属仓库的验证要求，保护受影响的行为和仍在使用的组件；在许可范围内运行有针对性的测试或构建，并保留必需的广泛／完整、依赖、迁移、转换、集成和发布门槛；影响未知或缺少有意义的覆盖时，必须扩大检查范围或明确指出差距，不得假定检查通过；
• 配置、作业、集成、文档和告警与新状态一致；
• 在适用情况下，迁移、数据和回滚方案均安全；
• 仅在另行授权部署时，检查确切的已部署修订版本和部署后证据。

记录选定范围及其理由、确切命令、结果、测试数量、环境和修订版本。缺少工具、命令失败或测试数量为零都不算通过。独立验收应检查已批准的清单和仍在使用的行为；当变更、失败或未解决的问题有此需要时重复检查，而不是自动重新运行完整测试套件。不得假定 CI 提供完整门槛，除非已核实其配置的工作流和仓库策略。

未关闭或已合并的 PR 表示已提议在源代码中退役，或已在源代码中完成退役。只有在已部署修订版本和部署后证据证明清单中的全部内容都已移除后，才能将生产环节标记为 retired。

输出

始终报告：

• 模式、仓库、候选范围、仓库修订版本，以及已知时的部署修订版本；
• 证据覆盖情况、失败、盲点和充足的观察周期；
• 零至三个按优先级排序的候选项，或针对指定目标的结论；
• 选定的指纹和已批准的清单（如有）；
• 已执行的确切变更，以及未通过的单独门槛；
• 验证凭证和最终候选状态；
• 规范问题 URL 和回读结果；未提供持久化授权时为 not-requested，无需持久化写入时为 not-needed，或说明持久化为何受阻。

关键规则

1. 调查必要性，而不是追求整洁。
2. 真实使用情况和运维义务优先于静态缺失。
3. 缺少遥测数据代表未知，绝不代表零。
4. 已安排的运行仅用于报告，即使允许写入问题也不例外。
5. 选择仅适用于一个指纹和清单。
6. 证据或影响范围发生变化，即使选择失效。
7. 一次运行最多退役一个候选项。
8. PR 不代表生产环境已退役。
9. 候选项少于三个且没有变更，是健康的结果。