maintain-verification-skill

维护验证技能

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

结果

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

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

编辑范围

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

Pass

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

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

2. 源码阶段。 每个功能文件安排一个只读子 Agent，并发启动。每个子 Agent 根据源码说明“这个面向用户的功能如何运作？”，引用依据并标出可能的文档偏差，然后给出一条简洁的实时验证方案。子 Agent 绝不操作应用，也不编辑文件。返回格式：功能摘要／源码入口／可能存在的偏差或无／一条验证方案。

3. 核对。 每个功能文件都必须有对应的摘要。将重叠的验证方案合并为尽可能少的应用状态。抽查引用所指的偏差；无需重新验证已确认无误的内容。检查近期变更，找出映射中遗漏的面向用户的界面；认定有遗漏前，必须找到具体的源码路径。

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

5. 分诊。 面向用户的描述错误或缺失 → 文档偏差，予以修复。功能正常但测试框架无法操作 → 测试框架缺口，予以修复；测试框架修复遵循与生成相同的辅助程序规则（脚本必须可执行，且技能正文必须记录调用方式）。应用行为确实存在问题 → 产品缺陷；记录下来告知用户，不要纳入此 PR。

6. 发布或停止。 对于有变更的情况：提交一个 PR，包含已验证的修正；先重新阅读每个已变更的文件。对于无变更或受阻的情况：不提交 PR，如实报告结果和覆盖范围。

将简洁的运行笔记（已覆盖的功能、无法触达的前置条件、已确认的偏差、结果）保存在临时位置；不要提交这些笔记。