当项目验证技能与功能地图随应用变化而过期时…

对由 /create-verification-skill 生成（或任何带功能地图的项目本地验证技能）做定期维护：每个功能并行读源码、逐个实机驱动、最多提交一个经过验证的修正 PR。

适用场景

解决思路

1. 先确定维护目标：找到项目本地、正文含启动/驱动章节和功能地图的验证技能（通常是 .cursor/skills/verify-*/）。有多个候选就问用户选哪个；一个都没有就停下并指向 /create-verification-skill，不要自己凭空造一个目标。
2. 做索引卫生：读功能地图的 README 并 glob 其同级文件，修复缺失、多余、重复或失效的条目。这一步要轻量，不要生成清单。
3. 发起源码波：为每个功能文件并发启动一个只读子代理。每个子代理从源码解释“这个面向用户的功能如何工作”，带引用地标出可能的文档漂移，并返回一份简洁的实机验证配方。子代理绝不驱动应用、绝不编辑文件。返回结构：功能摘要 / 源码入口点 / 可能的漂移或无 / 一份配方。
4. 做对账：确认每个功能文件都有返回摘要。把重叠的配方合并成尽量少的应用状态。抽查被引用的漂移点；对声称干净的部分不要重新证明。扫一遍近期改动，找出地图中缺失的面向用户界面——在判定缺失前必须给出具体源码路径。
5. 执行实机通过（即使源码看起来干净也必须做）：由协调者独自负责所有驱动；遵循验证技能自身的启动模型——服务器和 UI 用单个长驻实例串行驱动，短命 CLI 用每次驱动新建隔离会话（由该技能的 Launch 章节决定，不是本技能决定）。每个功能至少驱动一次，并在整个过程中保持三条不变量，无论是否失败：(1) 绝不在未做健康检查的情况下驱动一个自上次出现异常行为后未检查的实例——首次驱动前做 doctor，以会话为单位的每次新会话做 doctor，任何驱动失败后再做 doctor；当 doctor 看不到失败时（进程健康但 UI 卡死），重置到已知状态或重启，而不是指望它自己好；(2) 已捕获的证据必须在每次清理后存活，到其命名位置检查，不要假设；(3) 驱动启动的任何东西不得在该驱动失去用处后继续存在——失败迭代的残留物无论会话是卡住、已退出还是共享的都要清理（共享实例只清残留物，不清实例）。由技能漂移导致的 doctor 失败属于漂移：在编辑范围内修复并重试一次——只重启被修复影响的东西，不要更多——再判定为 blocked。无法到达的功能只有在给出具体前置条件（认证、权限、操作系统、外部状态）和尝试过的路径时才算 verified-unreachable；如果地图漏了该前置条件，那就是漂移。任何来自分诊的 harness 修复在发布前都要重新实机驱动。最终清理在本轮最后一次驱动（包括这些重新证明）之后进行，确保没有东西超出本轮存活（证据按技能要求保留）。
6. 做分诊：面向用户视角的描述错误或缺失 → 文档漂移，修掉。行为正常但 harness 驱动不了 → harness 缺口，修掉；harness 修复遵循与生成时相同的 helper 规则（脚本可执行、调用方式记录在技能正文中）。应用行为确实坏了 → 产品缺口；记录给用户，不要放进本 PR。
7. 发布或停止：changed 时提交一个只含已验证修正的 PR，提交前先重读每个改动过的文件。clean 或 blocked 时不提 PR，如实报告结果和覆盖情况。
8. 在临时位置保留简洁的运行笔记（覆盖的功能、不可达的前置条件、确认的漂移、结果）；不要提交它们。

适用边界 · 注意事项

• 不要编辑产品代码：地图描述的行为与应用不符时，要么是文档漂移（改地图），要么是产品回归（报告，不要在文档里掩盖）。
• 不要编辑验证技能自身目录以外的任何东西（其 SKILL.md、features/ 及它拥有的 harness 脚本）。
• 不要在没有具体源码路径的情况下判定某个功能缺失，也不要在没有具体前置条件和尝试路径的情况下判定功能不可达。