cleanup

name	cleanup
description	在任务完成后，对仓库内长期知识做深度整理、沉淀与规范审计。仅在用户明确要求 cleanup、最终沉淀、长期知识同步、收尾整理，或明确要求检查仓库规则执行情况时触发；不要用于中途续做、普通总结、状态同步或实现过程中的正常文档更新。默认保守触发，强制 cleanup 也不默认写入用户记忆。
argument-hint	请说明要沉淀的任务、范围或收尾目标；可留空

Cleanup Skill

这个 skill 用于把已经稳定下来的任务结论，整理成可长期复用的仓库内知识，并按需核对仓库规则是否被实践遵守。

它的职责是做终态的知识清理、去重、校正、沉淀，以及规则层的可核验一致性审计。

何时使用

在以下场景使用这个 skill：

• 用户明确要求 /cleanup、cleanup、做最终沉淀、更新长期知识、整理长期记忆
• 用户明确要求在任务收尾时同步仓库内知识、README、AGENTS 或仓库记忆
• 用户明确要求把已经稳定的任务结论整理成长期知识，而不是只生成下一 chat 的接续上下文
• 用户明确要求 检查规范、审计规则、规范体检、audit the rules，且对象是仓库规则、长期文档、指令、skill / agent / prompt / hook 等长期资产
• 用户报告长期文档、仓库记忆或规则文件已经过期、互相矛盾、存在死引用，或 published surface 与实际资产不一致

默认按显式长期沉淀或规则审计意图触发。 仅因为“当前阶段差不多做完了”，不足以自动进入 cleanup。

软提醒：当语义出现“阶段完成、适合沉淀”的信号（如“这个阶段做完了”“可以交给别人了”“新人能直接上手了”“准备收尾”）时，不自动执行 cleanup，只提示用户现在适合做一次。

不要路由到 cleanup

以下请求默认不要使用这个 skill（routing 判别——判断请求是否 cleanup 形，与下面硬约束的执行纪律不同轴，非重复）：

• 用户要“新开 chat 接着做”“交接到下一轮”“继续当前任务”
• 普通总结、recap、状态同步、进展汇报
• 实现过程中的正常 README、spec、docs、ADR、runbook 更新
• 代码评审、缺陷分析、方案比较、问题排查
• 只想检查代码质量、安全漏洞或 PR 风险，而不是审计仓库规则与长期知识
• 只是询问某条规则怎么理解，但没有要求核对仓库实践
• 只是讨论 cleanup skill 本身，而不是要执行一次真实的长期知识沉淀

如果用户只是要把当前工作续接到下一 chat，优先使用 handoff。

核心边界

• handoff 负责会话连续性
• 正式工件更新属于正常开发过程
• cleanup 只负责终态长期知识沉淀
• 规范审计是横切层（不是第四个 peer 层），负责“规则是否被实践遵守”的可核验部分，不替代代码审查或架构设计

同样是改文档：

• 为完成当前任务而改，不算 cleanup
• 为让长期知识系统保持准确、去重、可复用而改，才算 cleanup

硬约束

• 优先编辑和清理现有知识，不要把 cleanup 做成流水账追加器
• 先判断任务是否已经稳定，再决定是否执行 cleanup
• 默认只沉淀仓库内长期知识；用户记忆默认不写，除非用户再次明确要求
• 强制 cleanup 也不改变上面的默认边界
• 对仓库事实、正式工件和当前文件状态，优先信任直接读取证据，而不是对话回忆
• 不要把中间态判断、尚未验证的猜测或临时计划写进长期知识
• 不要把普通总结、handoff 内容或一次性叙事直接复制进长期载体
• 做规范审计时，规则真身永远在当前仓库、工作区或用户明确指定的指令文件里；不要把具体规则复制进 cleanup，只现场读取规则、提取可核验项、核对实践、处置结果（governance 审计纪律——规则现场读，与「不要路由」的请求判别不同轴，非重复）
• 🔴 默认只自动修安全、可逆、纯补齐的问题；目录重命名、删除资产、合并分叉规则入口、修改用户级全局配置等有外部影响的动作，列为“待你拍板”，不要自动执行
• 不要为了审计规范扩到整个用户目录或全盘仓库；默认只看当前仓库、当前任务触及资产，以及必要的直接上级规则

正常 cleanup 流程

PHASE 0: 验证请求

开始前先确认：

• 用户现在要的是长期知识沉淀，而不是中途续接（如果请求本质是“继续做”或“交接到下一轮”，改用 handoff）
• 用户是否同时要求规则 / 规范执行审计
• 稳定门：当前任务适合做长期沉淀，须满足
  • 核心目标已完成，或已停在稳定可交接终点
  • 不再依赖下一轮探索来决定主要结论
  • 已有正式工件足以承载稳定事实
  • 当前做长期沉淀不会把明显的中间态判断写死
  • 只做规范审计时，额外要求审计范围明确、主要对象能机械核验
• 当前知识整理范围主要落在仓库内，而不是用户级全局记忆

🛑 稳定门不满足时，不要直接进入正常 cleanup——先告诉用户当前任务还不够稳定，或改用 handoff。

🔴 CHECKPOINT（稳定门不满足 + 用户显式强制继续）：先告知（当前任务仍处中间态 / 直接沉淀可能污染长期知识 / 若只想切到下一 chat 继续做宜用 handoff）。 🛑 只有用户看过上述风险仍明确坚持，才继续（否则停在告知，不自行推进）；继续时写入边界仍守硬约束（仓库内优先，用户记忆须用户再次明确要求才写）。

如果用户只敲了 /cleanup、没说明要沉淀什么（裸调用或 argument 为空）：

• 先从本次会话和仓库最近变更（最近提交、当前工作区改动、刚稳定的文件）判断哪些任务已经收尾、值得沉淀
• 把推断出的沉淀范围在摘要里明确写出，让用户一眼能看出沉淀了什么、有没有漏
• 如果读完最近变更仍然判断不出稳定范围，先简短问用户一两个问题（例如“这次主要沉淀哪个任务 / 要不要顺带做规范审计”）再进入盘点
• 如果问了用户仍不明确范围，默认只盘点、列候选、不写文件，等用户确认范围后再动笔
• 不要在范围不明时大范围改文件，也不要因为“没说清楚”就直接拒绝、空转或敷衍

PHASE 1: 盘点长期知识载体

只读取与当前任务长期沉淀直接相关的最小范围：

• 当前任务涉及的正式工件
• 仓库内 README、AGENTS、docs 或其他长期知识文档
• 当前任务涉及的项目级指令、skill、agent、prompt、instruction、hook、manifest 和发布面 metadata
• 仓库记忆（如果当前环境支持）
• 当前任务明确触及的文件和变更事实

如果暂时拿不准当前 runtime 仓库里哪些路径属于长期知识载体，先读取 references/agent-paths.md 再决定扫描面。 不要为了“显得完整”而扫描整个仓库。

PHASE 1B: 规范执行审计（按需）

当用户明确要求规范审计，或本次 cleanup 涉及仓库规则、agent runtime 定制（custom instructions / rules / skills 等任何 runtime 的指令面）、插件发布面、README / CHANGELOG / metadata 等长期资产时，执行这一段。

先读取 references/governance.md，再按下面顺序做：

1. 读取当前仓库和必要直接上级的规则入口，确认哪个文件是权威来源
2. 从规则里提取能机械核验的约定，例如命名、必备文件、主指令入口、发布面清单、死引用和 metadata 一致性
3. 用最小范围的 ls、读取文件、grep 或 manifest 对照去核验现实
4. 安全、可逆、纯补齐的问题直接修；破坏性、有外部影响或需要权威判断的问题列入摘要“待你拍板”

不要把治理细则里的示例当成仓库规则。规则以现场读到的 AGENTS、README、manifest、instruction 或用户明确指定文件为准。

PHASE 2: 判断哪些信息值得长期保留

优先保留这些信息：

• 稳定的边界规则
• 长期会复用的命令、路径、约束和坑点
• 当前仓库中已经形成共识的结构事实
• 未来 agent 或维护者如果不知道就容易做错的内容

优先删除或避免写入这些信息：

• 中间态判断
• 一次性叙事
• 已过期事实
• 能从代码和正式工件直接看出的低价值重复信息

如果不确定“该补到哪里”或“哪些旧信息该删”，先读取 references/sync-matrix.md 再做取舍。

PHASE 3: 执行整理

执行顺序优先如下：

1. 删掉过期、重复和互相矛盾的旧知识
2. 合并已有条目，避免并排堆积同义内容
3. 只补真正缺失且已稳定的长期信息

如果这次 cleanup 涉及 skill、agent、prompt、instruction、README、metadata 或 CHANGELOG（任何 agent runtime 的资产），同步面优先按 references/sync-matrix.md 检查，不要只改单一入口。

编辑原则：

• 删旧优于追加
• 合并优于堆叠
• 精确优于冗长
• 仓库事实优于会话回忆

PHASE 4: 输出简洁摘要

完成后只输出简洁同步摘要：

• 改了哪些长期知识载体
• 为什么改
• 如果做了规范审计，哪些问题自动修复，哪些需要用户拍板
• 哪些东西没有动，为什么没动

不要把 cleanup 输出做成又一份 handoff。

立即执行

先判断这次请求应该走 handoff 还是 cleanup；若进 cleanup 但任务未稳，PHASE 0 的稳定门与强制 checkpoint 会处理。 如果进入 cleanup，先按需读取 references/agent-paths.md、references/sync-matrix.md 和 references/governance.md，再按最小必要范围读取证据，整理仓库内长期知识，并输出简洁摘要。