maintain-verification-skill

维护验证技能

应用一有变化，功能映射就会过时。此技能用于维护由 /create-verification-skill 生成的技能（或任何包含功能映射的项目本地验证技能）。严谨性的衡量单位是功能，而非每一句话：根据源代码覆盖每个功能文件，并在实际运行时验证每项功能，但无需将每条说明都转化为终端测试。

结果

选择一项，并说明是哪一项：

• clean — 每项功能都经过源代码和实际运行验证；没有值得发布的内容。不创建分支，不开 PR。
• changed — 通过一个 PR 发布已验证的文档、测试框架或映射修正。
• blocked — 无法完成覆盖，或无法安全发布已验证的修复。明确说明阻塞原因。

编辑范围

只能编辑验证技能自身的目录（其 SKILL.md、features/ 和该技能拥有的任何测试框架脚本）。运行期间绝不编辑产品代码：如果映射中描述的行为已不再由应用实现，则要么是文档偏差（修正映射），要么是产品回归（报告问题，不要在文档中掩盖）。

Pass

0. 定位目标。 找到要维护的验证技能：项目本地技能，其正文包含启动/驱动章节和功能映射（通常位于 .cursor/skills/verify-*/）。若有多个候选项，询问用户要选哪一个；若没有，停止操作，并指向 /create-verification-skill，不要自行臆造目标。

1. 索引卫生。 阅读功能映射 README，并 glob 查找其同级文件。修正缺失、多余、重复或失效的条目。保持轻量；不要生成清单。

2. 源代码调查。 为每个功能文件启动一个只读子 Agent，并发执行。每个子 Agent 根据源代码说明“这个面向用户的功能如何运作？”，引用证据标记可能的文档偏差，并返回一条简洁的实时验证步骤。子 Agent 绝不驱动应用，也不编辑文件。返回格式：功能摘要 / 源代码入口 / 可能的偏差或无 / 一条验证步骤。

3. 对照整合。 每个功能文件都必须有一份返回的摘要。合并重叠的验证步骤，尽可能减少所需的应用状态。抽查引用证据标记的偏差；对于没有疑点的声明，不要重新验证。检查近期变更，找出映射中遗漏的面向用户的界面；只有找到具体源代码路径后，才能判定遗漏。

4. 实时验证。 即使源代码看起来没有问题，也必须执行。由协调者负责所有驱动操作；遵循验证技能自身的启动模式——对于服务和 UI，使用一个长期运行的实例并串行驱动；对于短生命周期 CLI，每次驱动都使用全新的隔离会话（由技能的 Launch 章节决定，而非本说明）。至少验证每项功能一次，并在整个验证过程中始终遵守以下三项原则，无论遇到什么问题都不例外：(1) 绝不驱动自上次出现意外情况后尚未做过健康检查的实例——首次驱动前运行 doctor；以会话为单位时，每个新会话都运行 doctor；每次驱动失败后再次运行 doctor；若 doctor 无法发现故障（例如 UI 卡死，但进程正常），则重置到已知状态或重新启动，而不是寄希望于侥幸恢复；(2) 已捕获的证据必须在每次清理后保留，并在其指定位置核实，不可想当然；(3) 每次驱动启动的所有内容，都不能在失去用途后继续运行——无论会话卡住、已退出还是共享，都要清理失败迭代留下的残留（对于共享实例，只清理残留，不要关闭实例）。若 doctor 因技能偏差而失败，这属于偏差：在编辑范围内修复并重试一次——只重启因修复而失效的内容，不多做其他操作——之后才能将验证标记为 blocked。只有明确说明具体前置条件（身份验证、授权、操作系统、外部状态）并记录尝试过的路径后，才能将无法访问的功能标记为 verified-unreachable；如果映射遗漏了该前置条件，则属于偏差。分诊期间进行的任何测试框架修复，都必须在发布前重新实时验证。最后的清理必须在本次运行的最后一次驱动（包括这些重新验证）之后进行，确保没有任何内容在本次运行结束后继续运行（证据按技能要求保留）。

5. 分诊。 用户视角的说明错误或缺失 → 文档偏差，修复。功能正常但测试框架无法驱动 → 测试框架缺口，修复；测试框架修复遵循与生成相同的辅助工具规则（脚本必须可执行，并在技能正文中记录调用方式）。应用实际行为有误 → 产品缺陷；记录下来告知用户，不纳入此 PR。

6. 提交或停止。 若有变更：创建一个 PR，只包含已验证的修正，并先重新阅读每个变更文件。若无变更或受阻：不创建 PR，如实报告结果和覆盖范围。

在临时位置简要记录运行情况（已覆盖的功能、无法访问的前置条件、已确认的偏差、结果）；不要提交这些记录。