maintain-verification-skill

维护验证技能

以粗体或反引号标出的技能名称，或以 /<name> 运行的技能，指的是此技能目录旁的 ../<name>/SKILL.md 文件；未带前缀的原则名称指的是 ../principle-<name>/SKILL.md。阅读该文件并遵循其中的要求。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。每次 delegate_task 调用都遵循 ../poteto-mode/SKILL.md 中 Subagents 部分的默认设置。

应用一旦发生变化，功能地图就会过时。本技能是维护由 /create-verification-skill 生成的技能（或任何带有功能地图的项目本地验证技能）的例行流程。严谨度以功能为单位，而非逐句衡量：依据源码覆盖每个功能文件，并在实际运行中测试每项功能，无需将每条要点都转化为终端操作。

结果

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

• clean — 每项功能都经过源码和实际运行验证；没有值得提交的内容。不建分支、不提 PR。
• changed — 一个 PR 提交经过验证的文档、测试工具或地图修正。
• blocked — 无法完成覆盖，或无法安全提交经过验证的修复。准确说明阻碍因素。

编辑范围

只能编辑验证技能自己的目录（其 SKILL.md、features/ 以及它拥有的任何测试工具脚本）。运行期间绝不编辑产品代码：如果应用已不再表现出地图描述的行为，这要么是文档偏差（修复地图），要么是产品回归（报告问题，不要在文档中掩盖）。

流程

0. 定位目标。 找到要维护的验证技能：其正文包含启动和操作章节以及功能地图的项目本地技能（通常是 verify-*/）。在 .agents/skills/、.claude/skills/、~/.agents/skills/ 和 ~/.claude/skills/ 中查找，并将解析到同一实际路径的条目只计一次。有多个候选项 → 询问用户要选哪一个；没有候选项 → 停止，并指出应改用 /create-verification-skill，不要擅自创建目标。

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

2. 源码阶段。 为每个功能文件各启动一个 delegate_task 子任务，并发运行，使用 mode: "async"，title 标明功能名称，每个功能子任务使用一个 clientRequestId，并在本阶段内的重试中保持稳定，不设 target，以便在父模型上运行。子任务只会收到其简报，因此简报必须包含功能文件的绝对路径、“只读：仅检查，不写入，不运行 git 命令”、下方规定的返回格式，以及“不要委派”。每个子任务都要依据源码说明“此面向用户的功能如何运作？”，引用证据指出可能的文档偏差，并返回一条简洁的实际验证方案。子任务不得操作应用，也不得编辑文件。返回格式：功能摘要 / 源码入口 / 可能的偏差或无 / 一条方案。结束本轮，等待完成通知唤醒你。

3. 核对。 每个功能文件都必须有返回的摘要。将重复的方案合并到尽可能少的应用状态中。抽查所引用的偏差；无需重新验证确认无误的声明。检查近期变更，找出地图中缺失的面向用户界面——只有找到明确的源码路径，才能认定其缺失。

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

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

6. 提交或停止。 对于已更改的内容：创建一个包含已验证修正的 PR，先重新阅读每个已更改的文件，使用 gh pr create 创建 PR，并立即对其 URL 调用 link_pull_request。对于干净或受阻的情况：不要创建 PR，如实报告结果和覆盖范围。

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