メニュー
在任务完成后，对仓库内长期知识做深度整理、沉淀与规范审计。仅在用户明确要求 cleanup、最终沉淀、长期知识同步、收尾整理，或明确要求检查仓库规则执行情况时触发；不要用于中途续做、普通总结、状态同步或实现过程中的正常文档更新。默认保守触发，强制 cleanup 也不默认写入用户记忆。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/iasiv5/ob-harness --skill cleanupコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
在开始实现前，把需求澄清成设计文档。适用于新增功能、修改行为、组件设计、接口设计、流程改造、架构取舍和多方案比较。只要改动跨文件、改行为或涉及多方案取舍，就值得先做设计，无论体量大小；单点直改不必走本 skill。用户说'先想一下''先给方案''先规划一下''先比较两种做法'时优先使用这个 skill。
为新的 chat / 新会话生成面向下一会话目标的 handoff / continuation context。仅在用户明确要把当前工作交接到新 chat 继续时触发；不要用于普通总结、状态同步、代码评审、changelog 或文章摘要。基于只读证据输出可直接粘贴到新 chat 的中文优先接续上下文。
在已有设计文档或清晰需求、但还没开始实现时，把目标写成可执行的分步实施计划。适用于跨文件改动、非平凡功能、重构，以及任何需要明确测试或验证命令的任务。只要用户要把已定需求、现成 spec、明确目标，或 /grill-with-docs / /grilling 后达成的共识，拆成 step-by-step plan，就优先使用这个 skill；如果设计还没定，不要硬写计划，退回 brainstorming 或 grill-with-docs 把设计做扎实。
SOC 職業分類に基づく
SKILL.md を表示中
| name | cleanup |
| description | 在任务完成后，对仓库内长期知识做深度整理、沉淀与规范审计。仅在用户明确要求 cleanup、最终沉淀、长期知识同步、收尾整理，或明确要求检查仓库规则执行情况时触发；不要用于中途续做、普通总结、状态同步或实现过程中的正常文档更新。默认保守触发，强制 cleanup 也不默认写入用户记忆。 |
| argument-hint | 请说明要沉淀的任务、范围或收尾目标；可留空 |
这个 skill 用于把已经稳定下来的任务结论，整理成可长期复用的仓库内知识，并按需核对仓库规则是否被实践遵守。
它的职责是做终态的知识清理、去重、校正、沉淀，以及规则层的可核验一致性审计。
在以下场景使用这个 skill：
/cleanup、cleanup、做最终沉淀、更新长期知识、整理长期记忆检查规范、审计规则、规范体检、audit the rules，且对象是仓库规则、长期文档、指令、skill / agent / prompt / hook 等长期资产默认按显式长期沉淀或规则审计意图触发。 仅因为“当前阶段差不多做完了”，不足以自动进入 cleanup。
软提醒：当语义出现“阶段完成、适合沉淀”的信号（如“这个阶段做完了”“可以交给别人了”“新人能直接上手了”“准备收尾”）时，不自动执行 cleanup，只提示用户现在适合做一次。
以下请求默认不要使用这个 skill（routing 判别——判断请求是否 cleanup 形，与下面硬约束的执行纪律不同轴，非重复）：
如果用户只是要把当前工作续接到下一 chat，优先使用 handoff。
handoff 负责会话连续性cleanup 只负责终态长期知识沉淀同样是改文档：
开始前先确认：
handoff）🛑 稳定门不满足时，不要直接进入正常 cleanup——先告诉用户当前任务还不够稳定，或改用 handoff。
🔴 CHECKPOINT（稳定门不满足 + 用户显式强制继续）：先告知（当前任务仍处中间态 / 直接沉淀可能污染长期知识 / 若只想切到下一 chat 继续做宜用 handoff）。
🛑 只有用户看过上述风险仍明确坚持，才继续（否则停在告知，不自行推进）；继续时写入边界仍守硬约束（仓库内优先，用户记忆须用户再次明确要求才写）。
如果用户只敲了 /cleanup、没说明要沉淀什么（裸调用或 argument 为空）：
只读取与当前任务长期沉淀直接相关的最小范围：
如果暂时拿不准当前 runtime 仓库里哪些路径属于长期知识载体，先读取 references/agent-paths.md 再决定扫描面。 不要为了“显得完整”而扫描整个仓库。
当用户明确要求规范审计，或本次 cleanup 涉及仓库规则、agent runtime 定制（custom instructions / rules / skills 等任何 runtime 的指令面）、插件发布面、README / CHANGELOG / metadata 等长期资产时，执行这一段。
先读取 references/governance.md，再按下面顺序做：
ls、读取文件、grep 或 manifest 对照去核验现实不要把治理细则里的示例当成仓库规则。规则以现场读到的 AGENTS、README、manifest、instruction 或用户明确指定文件为准。
优先保留这些信息：
优先删除或避免写入这些信息：
如果不确定“该补到哪里”或“哪些旧信息该删”，先读取 references/sync-matrix.md 再做取舍。
执行顺序优先如下：
如果这次 cleanup 涉及 skill、agent、prompt、instruction、README、metadata 或 CHANGELOG（任何 agent runtime 的资产），同步面优先按 references/sync-matrix.md 检查，不要只改单一入口。
编辑原则：
完成后只输出简洁同步摘要：
不要把 cleanup 输出做成又一份 handoff。
先判断这次请求应该走 handoff 还是 cleanup；若进 cleanup 但任务未稳，PHASE 0 的稳定门与强制 checkpoint 会处理。
如果进入 cleanup，先按需读取 references/agent-paths.md、references/sync-matrix.md 和 references/governance.md，再按最小必要范围读取证据，整理仓库内长期知识，并输出简洁摘要。