doc-updatelisted

## 核心目标 下次换一个全新 Agent 进来，只读现有文档就能顺畅理解上下文、接手并完成工作。 每步更新都以此为检验标准：*如果现在换一个 Agent，它不看本次会话、只读这些文档，能顺利干活吗？* ## 与 memory 的边界 - 本 skill 只更新对应 skill 文件或当前项目文档，不读取或写入任何 memory。 - 项目规则禁用 memory 时，本 skill 仍可正常执行；禁止把"禁用 memory"误判为"禁用复盘与文档更新"。 ## Step 0：判定是否需要执行 跳过条件（任一命中则直接告知用户"本次无需更新"并结束）： - 纯问答/闲聊，无代码、配置、流程、规则变动 - 所有发现已存在于现有文档（先搜再判断） - 信息仅对当前会话有用，未来会话不会重现 - 项目规则明确禁止修改 skill / docs ## Step 1：回顾会话，提取可复用发现 **召回（先扫全）**：把本次会话当作即将被永久删除——任何没落进文档的信息都会随之消失。带着这个前提扫一遍会话，重点回放两类不留 artifact 的信息源（代码变动会留在 diff 里，它们只在对话上下文里，最容易漏召回）： - **逐条回放用户的每一次插话**（纠正、要求、否决、建议；对照下方「用户纠正信号细化检查」清单逐条比对，防漏）。 - **逐段回放自己的试错弯路**：反复尝试多轮才走通、中途被否决 / 失败的方案。最终产出只体现正确答案，看不出中间排除过什么；记录时必须带"哪些路走不通 + 根因 + 最终解法"，不只记现象或只记结论。 **提炼（主动归纳，禁止甩给用户）**：在召回之后，主动判断：本会话是否沉淀出可复用的工作方式、检查清单、排障路径、命名/落盘约定、验证口径？若有，直接写成可执行条目并进入后续落盘步骤。 - **禁止**对用户说「能不能从会话总结一套最佳实践」「要不要沉淀一下经验」之类征求意见的话——是否值得落盘由本 skill 自行判定，用户只需在 Step 4 看到更新结果或「本次无需更新」。 - **禁止**把一次性操作流水账包装成「最佳实践」；只落盘未来会话仍会用到的稳定约定。 - 写成条目时用祈使句 / 检查清单口吻（做什么、何时做、禁止什么），不要写成会话纪要。 **判据（再筛准）**：核心问题——*换一个全新 Agent 只读文档，它能顺畅接手吗？* 让它少踩坑、少重新摸索的 → 记；能从代码 / git / 现有文档直接拿到的 → 不记。下列是这条判据的常见命中： - 新发现的业务规则、设计机制、架构约束 - 踩过的坑（含根因和解法） - **验证有效的模式、工作流、检查清单**（含本会话归纳出的稳定做法）——用「非显然元素测试」判定：模式里是否含"下次换新 Agent 能省摸索"的非显然元素（关键决策、绕坑动作、顺序选择、验证口径）？只有显然步骤的漂亮流水账 → 不记 - 用户给出的偏好/反馈/纠正——**判别一次性 vs 长期**：话里含「以后 / 每次 / 都 / 不要再」，或是对你已做出动作的纠正 / 否决 / 返工要求 → 默认按长期偏好落盘；纯描述本次任务范围的（如「这次只改 X」）才算仅对当前会话有用 - **用户纠正信号细化检查**（对照清单逐条扫会话，防漏召回——笼统的「用户纠正」最容易漏掉以下几种）： - **重定向**：用户把方案 / 话题引向另一方向（不等于批评，单独成信号） - **不满 / 困惑 / 摩擦**：用户没说「你错了」，但表达困惑、含糊不满、或绕晕