1. 另一个 Skill 负责同一个决策
职责重叠是最常见的移除原因。如果两个包都在规划变更、审查差异或驱动同一浏览器流程，团队就必须协调两份产物和两套权限边界。
保留范围更窄、证据更清楚的候选。记录移除后损失的能力；如果没人能说出损失了什么，第二个 Skill 就没有证明自己的位置。
2. 来源已经无法重新构建
仓库消失、安装路径无法对应已审查来源、引用脚本未经审查发生变化，或固定提交无法复现时，应移除或隔离该 Skill。
仓库 HEAD 变化本身只是审查信号。真正决定是否处理的是已收录 Skill 文件或引用资产是否发生实质变化。
3. 请求了工作流没有使用的权限
只需生成报告的任务，不应需要发布、部署、发消息、删除或广泛凭据访问。如果首次代表性运行没有用到某项权限，就移除权限，或换成范围更窄的 Skill。
安装范围也是权限边界的一部分。如果只有一个仓库需要该流程，就应移除个人范围安装。
4. 没有人查看或使用产物
生成报告、发现、截图、计划或摘要，却没有明确审查者的 Skill，只是在增加活动，而不是增加证据。如果产物反复被忽略，应缩短流程或移除它。
只有当产物改变决策、捕获已知风险或保留可重复证据时，自动化才合理。数量本身不是价值。
5. 同一个受控任务连续失败两次
在同一个小型代表性任务上重复失败，比宽泛兼容标签更有说服力。如果 Skill 需要无法解释的权限扩大、写出范围、调用未列出的服务，或产物无法通过验收，应移除或隔离。
保留失败记录、来源提交、环境和回滚结果。移除不代表它在所有环境都失败，只代表当前组合无法证明继续保留合理。
- 准确失败可以重复。
- 记录了来源提交和 Agent 环境。
- 没有更简单的权限或配置修复能够解释结果。
- 回滚恢复了原有状态。
- 替代方案有独立验收测试，而不只是相同宣传承诺。
每月十分钟清理
列出所有已安装 Skills 的范围、来源、最近使用时间、权限、产物负责人和最近一次成功受控测试。移除明显重叠、隔离来源不清的项目，只重新测试仍重要的工作流。
更小的组合能改善发现效率与权限清晰度。目标不是永远保持五个，而是用最少 Skills 覆盖真正可观察、可审查的工作。