这两天做了一个有意思的事情，把我的全部的 Skills 删除了将近 1/3，同时把所有项目的上下文也都优化了一下，感觉干净清爽了不少，我认为随着模型能力越来越厉害，我们有经常去更新裁剪我们的项目的一些给到模型的上下文信息，防止你的内容反而阻碍了模型的发挥。
于是我就把最近做的继续沉淀成一些大伙也用得上的提示词，可以直接给到你的 Agent 去帮你优化你的项目的内容要求和 Skills，已经安装 Waza 的小伙伴可以直接更新到最新然后说「帮我精简一下规则」就好，也可以 Copy 下面内容给你的Agent。
帮我精简这个项目给 Agent 的上下文和我装的 Skills，按下面的要求来，先整理出清单给我确认，确认前先不改任何文件。
1. 先盘点每轮对话都会加载的内容，包括根目录的 AGENTS.md / CLAUDE.md、全局规则、没写 paths: 的 .claude/rules 和每个 skill 的描述，看各占多少字，再看按需加载的部分，这里不少看着臃肿的内容可能不是写多了，而是放的位置不对。
2. 逐段给出处理方式，分成修、删、挪、改写、保留五种，挪的写清目的地，每条附一句原因，做成一张清单给我确认。
3. 逐句判断删掉后你的行为会不会变，把类似这种「先读再改」「跑测试」「注意边界」你本来就会做的描述删掉，拿不准的可以先保留找我确定。
4. 我们更加推崇是给 Agent 写目标，少些如何实现的路线，写清做完是什么样、怎么算完成、要什么证据，一个步骤删掉后你还能换条路做到同样结果就删掉，只有顺序本身是约束的才留下来，比如先验证再发布、先确认再删除这种需要保留。
5. 同一种要求说了三遍，换成一个你本来就懂的词语，比如「快、确定、开销小」可以写成 tight；「要简洁」这类口号换成一个更好理解的想想的词语比如「报告腔」，然后再配一组 NO / OK 例子。
6. 把对应内容放对位置，需要判断的进 skill，同样输入总是同样输出的改成脚本或 hook，项目命令和发布步骤进项目指南，跨项目的硬约束才放进全局规则，遇到「做 Y 之前先读 X」这类要求改成做 Y 时由 hook 把 X 注入进来更好。
7. skill 描述只写做什么、什么时候用、不用于什么，近义词移到 when_to_use，只有部分场景用到的内容移到 references；判断一个 skill 有没有人用，要看真实调用记录，不要只 grep 名字，要删的也先列给我看一下。
8. 这些内容不要删除：
- 我的偏好、被否掉的方案和原因、机器环境。
- 不报错的坑，以及看着像出错其实正常的现象。
- 描述句里「从不写入」「不上传」这类半句约束。
- 删数据、需要花钱、要发布、提权、改写已推送历史这些不可逆操作的规则。
- 我们带日期的拍板决策记录。
9. 内容先移到对应正确的位置再来压缩，能整行搬到按需加载的文件里就整行搬，不要边搬边改写，不可逆的规则原样整段搬。
10. 把内容搬到能自己加载的地方可以参考这些技巧：
- 提交、发布、回复、删除这类对话里随时会触发的规则留在根目录。
- 挪进 docs/ 的要在根目录留一句什么时候去读。
- 根目录不要建 CLAUDE.md，它会让 Claude Code 不再读 AGENTS.md。
- 项目里重复全局规则的句子，只有在我用的每个工具都读全局规则时才删。
11. 改完以后自己去查一遍：paths: 里的 glob 都要能匹配到真实文件，grep 一遍拆走的旧文件名，再列出所有消失的行，每一行都要对上清单里我确认过的删除。
12. 交给一个没参与精简的 Agent 查有没有删过度了，只给它消失的行和仓库，不给你的结论，让它搜关键名词而不是整句，意思在哪都找不到的原样恢复。
13. 验证移过去的内容真的会被加载：在新文件里埋一个暗号，开一个新会话，先读一个匹配的文件再问它暗号，然后读一个不匹配的文件做反向对照。
14. 最后全部做完以后，可以帮我沉淀一下这个思路，方便以后有模型升级的时候，我可以再来跑一遍。
