SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场create-verification-skill

create-verification-skill

测试与质量

查看项目

更新于 10-15 14:40

技能介绍

用途

create-verification-skill 用于为项目生成一个“项目本地验证技能”，让代理能够像真实用户一样驱动应用并证明行为：启动应用、按用户方式操作某个功能、采集证据。生成物写入 .claude/skills/verify/，并命名为 verify。

在仓库根目录，同名项目技能会替代 Claude Code 内置的 /verify（内置版本仅用户可调用），因此所有点名该驱动技能的操作手册都可以调用项目版本（需要 Claude Code 2.1.200 或更高版本）。在 monorepo 中，应写入被触及的包目录。生成器的输出是写给下一个代理的，而不是写给人：它会在任务中途被一个从未见过该应用的代理冷读。

主要能力

1. 访谈仓库，而不是用户

从代码库中回答以下问题，只向用户询问无法观察到的事项：

  • Surface：用户实际接触什么？Web UI、CLI/TUI、桌面应用、API、移动应用、库？一个仓库可能有多个，选主要的一个并记录其余。
  • Run：应用如何在本地启动？优先使用仓库自身文档化的开发命令（package scripts、Makefile、README quickstart）。记录端口、环境变量、种子数据、认证。
  • Drive：代理如何以编程方式与之交互？优先使用现有 harness——Playwright/Cypress 规格、expect 脚本、PTY 辅助工具、可 curl 的端点、调试端口。之后才选择通用配方：Web 和 Electron 用浏览器/CDP，CLI/TUI 用 tmux/PTY harness，服务用纯 HTTP。
  • Observe：可以采集什么证据？截图、终端记录、响应体、日志、退出码、数据库状态。
  • Isolate：能否并行运行两个实例（端口、数据目录、配置文件）？如果不能，在生成的技能中说明：拒绝双重驱动共享实例，好过破坏用户会话。

如果检出代码无法按原样构建或启动，先修复（或精确报告）再生成；针对损坏基线编写的技能会教出错误步骤。当无关的缺失资产阻塞启动（API 从不提供的静态目录、示例配置）时，生成的技能可以创建它，并明确标记为验证脚手架，在清理时移除。

2. 生成技能

写入 .claude/skills/verify/SKILL.md，包含 YAML frontmatter（name: verify，以及一个描述，说明应用、接触面以及何时使用它——没有 frontmatter 技能不会注册，带 disable-model-invocation 则模型无法调用），以及以下章节，每节都基于访谈实际发现（不留占位符）：

  • Launch：启动应用进行验证的精确命令，以及如何判断就绪（日志行、提示符）。启动必须从空数据目录到达可用状态，包括迁移和种子数据。就绪意味着可用，而不仅仅是进程有响应。数据库健康检查可能通过，而其初始化脚本仍在运行。包含 teardown。对于短生命周期的 CLI 或 TUI，没有需要保持存活的服务器：launch 意味着构建二进制（或安装依赖）一次，然后在各自隔离的 PTY 或 tmux 会话中启动每次驱动。
  • Doctor：一个只读检查，回答“这个实例值得驱动吗？”——进程是否运行、版本/构建是否正确、端口是否属于我们、认证是否有效。任何看起来不对时，代理首先运行它。
  • Drive：harness 配方，使用本仓库的真实选择器/命令，而非示例。优先使用稳定句柄（ARIA 标签、data 属性、提示字符串、路由路径），而非坐标和 Tab 顺序。
  • Evidence：为证明采集什么、放在哪里。说明证明标准：走真实用户路径，而非内部 setter 或仅测试端点；采集动作和结果状态，而不仅是最终屏幕；验证副作用（写入的文件、插入的行、发送的消息）与可见内容；仅在既有生产边界隔离外部系统时才使用 mock。当安全路径是 dry-run 或测试模式时，通过观察（文件、网络、git refs）验证它实际跳过了什么，而不是相信它的名字：有些 dry-run 仍会访问网络或打开浏览器。
  • Cleanup：如何拆除本次运行创建的实例。绝不按进程名杀进程；只杀自己启动的。清理移除实例和临时状态，绝不移除证据：证明产物在 teardown 后仍存活，位于技能指定的位置。
  • Helpers：技能附带的任何脚本都可执行，其调用方式在技能正文中展示。需要读者逆向工程的辅助工具不算辅助工具。

3. 播种功能地图

创建 .claude/skills/verify/features/README.md，以及每个可识别的用户可见功能一个文件（起步目标为前 3-5 个，来自路由、命令、菜单或文档）。遵循 references/feature-map-example/ 中的形状，包含 README 索引和每个功能一个文件。每个文件从用户视角回答：功能是什么、如何到达、如何用 harness 驱动、什么可观察的最终状态证明它有效。四个 H2 为 Sub-features、How to get to it (user POV)、Driving it with <harness>、Gotchas。如果种子数据缺少某个旅程所需的前置条件，该旅程报告失败，原因写入该功能的 Gotchas。绝不要为了让旅程通过而弱化它。地图是仓库维护的验证来源；当地图列出多个入口点时，只驱动一个方便入口的证明是不完整的。

4. 交付前证明生成的技能

端到端运行其自身指令一次：launch、doctor、驱动一个已映射功能（一个就够；地图的存在是为了后续运行覆盖其余）、采集证据、清理。清理后，确认证据仍存在于指定位置——吃掉证明的清理会使此步骤失败。修复失败之处，并在每次失败迭代后也运行生成的清理，以免损坏的尝试遗留进程和端口。从未执行过的生成技能是草稿，不是交付物。如果在真实目标的替身中证明（用容器代替全新 VM、用本地栈代替远程栈），列出替身做了而目标不会做的每个设置步骤。这些步骤在真实目标上运行覆盖之前保持未验证。

5. 提供维护循环

指向 /maintain-verification-skill，以便在应用变化时保持地图诚实。仅在用户询问时建议节奏。

使用方式

该技能通过生成项目本地技能来使用。生成物为 .claude/skills/verify/SKILL.md 及 features/ 目录。在 Codex 上，遵循此技能前先阅读平台映射，包括其每个技能的说明。在 GitHub Copilot 上，遵循此技能前先阅读平台映射，包括其每个技能的说明。

适用场景

适用于任何需要脚本化方式驱动真实应用并证明行为的严肃项目：启动应用、按用户方式操作功能、采集证据。适合 Web UI、CLI/TUI、桌面应用、API、移动应用、库等多种接触面。

限制

  • 需要 Claude Code 2.1.200 或更高版本才能让项目技能替代内置 /verify。
  • 如果检出代码无法按原样构建或启动，需先修复或精确报告，否则生成的技能会教出错误步骤。
  • 如果实例无法并行运行，生成的技能会说明拒绝双重驱动共享实例。
  • 生成技能必须端到端自证一次，否则只是草稿。
  • 在替身中证明时，替身特有的设置步骤在真实目标上运行前保持未验证。
  • 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。