编码会话后改进代理环境：用回顾从会话日志和仓库配置中提炼导航…

在一次编码会话结束后，通过回顾会话日志和仓库配置，按严重程度提出能改进未来编码代理运行环境的可执行改动。

适用场景

解决思路

1. 调用 Skill 工具并传入 `writing-for-agents`，获取写作风格指南，作为后续改进建议的表达规范。
2. 阅读用户指定会话的一手来源；如有需要，在本机搜索会话日志；用户未指定会话时，默认回顾当前会话。
3. 在导航类别中找改进候选：评估代理找到正确文件有多容易、文件之间是否有隐藏依赖、加入导航指针是否会让查找更容易；当会话花很长时间才找到信息时，提出导航指针等改进。
4. 在自动检查类别中找改进候选：检查是否有 lint、类型检查、测试、文件系统 linter 等自动检查能捕获代理犯的错误。
5. 先阅读仓库自己的检查命令：`package.json`/构建工具的 `lint`/`check` 脚本、CI workflow；如果已有检查但未接入或静默损坏，把「接入/修复现有检查」作为发现，而不是重新发明检查。
6. 把「没有任何护栏」本身作为发现：仓库既没有 pre-commit hook，也没有 CI job 运行其 lint/typecheck/test 命令时，指出这是持续错过的机会，而不是中性默认；当代理犯了自动检查本可捕获的错误，或仓库完全没有护栏时，提出相应检查。
7. 在编码标准类别中找改进候选：判断 reviewer agent 是否应被赋予新规则来执行，或现有规则是否应删除/澄清；当 reviewer agent 漏掉错误时提出。
8. 对违规先分类：机械性违规（固定语法模式、禁用 API、import 形态、文件位置规则）应得到确定性检查，不留例外：在仓库自己的 linter 中加自定义规则、新增 pre-commit hook，或新增 CI job，选择在仓库语言和现有护栏下成本最低的一种。
9. 默认优先构建自动检查，而不是写规则文本；只有真正的判断题（跨文件一致性、「符合周围风格」、任何护栏无法替代的内容）才留给 `CODING_STANDARDS.md`。
10. 在全局 `AGENTS.md` 类别中找改进候选：检查是否有 steering 指令应迁移到编码标准或自动检查；当仓库中或用户全局范围的 `AGENTS.md` 特别大时提出。
11. 在工具经济性类别中找改进候选：检查代理是否做了可精简的昂贵工具调用，是否有自定义工具（CLI、MCP）特别 token 低效；当代理做了昂贵工具调用时提出。
12. 在无效指令（no-ops）类别中找改进候选：检查 steering 文件中是否有不改变代理行为的指令；当 steering 文件又大又难用时提出。
13. 在信息访问类别中找改进候选：寻找增加代理信息访问的机会，例如 tee 开发服务器日志、对第三方服务提供只读访问；当关键信息对代理不可用时提出。
14. 将候选按严重程度排序后呈现给用户。
15. 遵循实现与审查两阶段原则：实现代理 context pressure 最大，负责探索、写代码、调试失败；审查代理 context pressure 最小，接收 diff，无需探索，通常不需写代码或调试；因此由审查代理负责施加编码标准，而不是实现代理。
16. 文件使用建议：`CLAUDE.md`/`AGENTS.md` 会被推送到任何在该仓库工作的代理的上下文窗口，应极其节制地使用，通常只放指向其他文件的导航指针。
17. `CODING_STANDARDS.md` 在审查时读取，而不是实现时读取；如果标准文件超过 1,000 行，向其中加入指向 docs 文件夹的导航指针。
18. Docs 作为参考文件，由其他文件指向；写新文档前先找现有文档。
19. Skills 可用于文档（因为其 description 会进入代理上下文窗口），或用于用户调用的命令；遵循 `writing-for-agents` 技能中的建议。

适用边界 · 注意事项

• 不适用于只想回顾会话内容或做代码审查，而不打算改进代理运行环境时。
• 无法访问会话日志或仓库配置（如 `AGENTS.md`、CI、lint 脚本）时，不要强行给出环境改进结论。
• 若团队没有使用编码代理/审查代理，或没有可维护的 steering 文件，则大部分建议无落点。