mcpField
M
maintain-verification-skill

maintain-verification-skill

github.com/ericlitman测试与质量53847 次安装1 周前更新
代码仓库

关于 maintain-verification-skill

用于维护带功能映射的项目本地验证技能，指导检查源码并进行应用实测。它区分文档、测试工具和产品问题，并以干净、有改动或受阻作为结果。

主要功能

  1. 01检查功能映射条目
  2. 02逐项对照源码审查功能
  3. 03在运行中的应用里实测功能
  4. 04区分文档、工具和产品问题
  5. 05报告干净、有改动或受阻结果

适用场景

  1. 01应用变更后更新验证技能
  2. 02检查功能文档是否过时
  3. 03在实测中发现测试工具缺口

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ericlitman/open-pstack --skill maintain-verification-skill

安装后在 Claude Code 中输入/maintain-verification-skill确认已加载。

详细介绍

维护验证技能

应用一旦发生变化，功能地图就会逐渐过时。本技能用于维护由 /create-verification-skill 生成的技能（或任何带有功能地图的项目本地验证技能）。严谨性的衡量单位是功能，而不是每句话：根据源代码覆盖每个功能文件，并在运行中的应用里逐一验证每项功能，无须把每条要点都变成终端命令。

平台说明。 在 Codex 或其他非 Claude 运行时中，下方按功能并行读取源代码的方式对应于 spawn_agent 扇出；项目本地技能位于运行时的技能目录中，而不是 .claude/skills/。请参阅 codex-tools.md。

结果

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

  • clean — 每项功能都经过源代码和运行验证；没有值得提交的内容。不建分支，不提 PR。
  • changed — 提交一个 PR，其中包含经验证的文档、测试框架或功能地图修正。
  • blocked — 无法完成覆盖，或无法安全提交经验证的修复。明确说明受阻原因。

编辑范围

只编辑验证技能自身的目录（其中的 SKILL.md、features/ 和它自带的测试框架脚本）。运行期间绝不编辑产品代码：如果应用不再表现出地图所描述的行为，那么这要么是文档与实际不符（修正地图），要么是产品回归（报告问题，不要用修改文档来掩盖）。

流程

  1. 定位目标。 找到要维护的验证技能：项目本地技能，其正文包含启动/驱动章节和功能映射（通常位于 .claude/skills/verify-*/）。如果有多个候选项 → 询问应选哪一个；如果没有 → 停止，并指向 /create-verification-skill，不要擅自创建目标。

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

  3. 源码阶段。 每个功能文件启动一个只读子 Agent，并发执行。每个子 Agent 根据源码说明“这项面向用户的功能如何工作？”，标记可能存在文档偏差之处并附上引用，然后返回一条简洁的在线验证方案。子 Agent 绝不驱动应用，也不编辑文件。返回格式：功能摘要 / 源码入口 / 可能的偏差或无 / 一条验证方案。

  4. 协调核对。 每个功能文件都必须有摘要返回。将重叠的验证方案合并为尽可能少的应用状态。抽查引用所指的偏差；不要重复验证没有问题的内容。检查近期变更，找出映射中遗漏的面向用户界面——只有找到具体源码路径，才能认定存在遗漏。

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

  6. 分诊。 面向用户的描述错误或缺失 → 文档偏差，修复。功能正常但测试框架无法驱动 → 测试框架缺口，修复；测试框架修复遵循与生成流程相同的辅助文件规则（脚本必须可执行，且技能正文必须说明调用方式）。应用行为本身确实损坏 → 产品缺口；记录并告知用户，不要纳入此 PR。

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

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

评论

支持 Markdown