维护错题本与项目规则

把已发生的错误整理成下一次能改变行动的教训，再判断哪些应成为项目规则。每条教训连接失败证据、适用范围、纠正动作与验证；规则晋升和问题修复分别记录。

只调查当前异常时使用 investigating-findings，只质检修复方案时使用 checking-solutions。本 Skill 在用户要求复盘、维护或提炼规则时进入，不给每次修复附加一套项目文档。

确定维护范围

读取项目规则、已有错题本、规范与相关记录，沿用权威位置、编号、统计口径和审查范围。明确本轮是记录一个错误、整理一段历史还是提炼长期规则，以及允许修改的文件。已授权维护时直接完成可确定的编辑；只审查时交付可定位的建议。

没有特殊约定或既有权威位置时，在项目根目录用 LESSONS.md 保存教训，将提炼出的长期规则直接写入根目录 AGENTS.md，保留其中其他内容。规则写明适用条件、动作与检查方法，原始事故和长证据仍留在错题本。已有独立规范时继续沿用，AGENTS.md 或等价入口用有触发条件的短指针连接它；规则已在 AGENTS.md 时无需另建规则文件或自指链接。无需采用特定宿主或 OpenSpec。创建模板、整理条目或添加入口不等于建立自动执行钩子；定时任务、外部 Issue 与全局配置仍需对应授权。

从证据形成教训

按本轮范围读取实际变更、报告与执行结果，优先找修后返工、过早完成和验证不足。记录起止版本、过滤条件及未读部分；连续审查标记只能推进到完整覆盖的位置，稀疏审查单列范围。

事件材料只有口头或任务描述时，不虚构文件名、错误行号、工具版本和运行日志；先以该描述作为来源，保留字段、版本、原始错误和原始包未提供的边界。除非用户明确要求在当前回复维护文档，交付可粘贴的教训建议和位置；用户授权编辑时才写入权威位置。

先区分观察、原因假设、已支持机制和未知，再写“在什么条件下应怎样行动，在哪里检查”。原因不明也可以记录止损与取证动作；重试通过、补丁合并或文档新增不能替代相应验证。成功纠正案例可作为“正确做法”保留直接证据。