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

create-verification-skill

测试与质量

查看项目

更新于 10-16 07:51

技能介绍

用途

create-verification-skill 用于为项目生成一个本地的验证技能（verification skill）。每个严肃的项目都需要一种脚本化的方式来驱动真实应用并证明其行为：启动它、像用户一样操作某个功能、并采集证据。该技能将这一过程生成为项目本地的技能目录（.agents/skills/verify-<app>/），并针对具体仓库进行定制。生成的内容是写给下一个智能体阅读的，而不是写给人看的——它会被一个从未见过该应用的智能体在任务中途冷读。

主要能力

1. 访谈仓库而非用户

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

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

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

2. 生成技能

编写 .agents/skills/verify-<app>/SKILL.md，包含 YAML frontmatter（name: verify-<app> 和一个描述，说明应用名称、界面类型以及何时使用它——没有 frontmatter 技能永远不会注册）以及以下章节，每个章节都基于访谈实际发现的内容（不留占位符）：

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

3. 播种功能地图

对于 Paperclip：阅读地图契约并使用同级的 maps/feature-map/ 和 maps/agent-access-map/ 目录。生成的验证技能消费这两张地图并报告漂移；维护负责更新它们。复用现有功能文件并保留 Poteto 的产品格式。每个新功能文件都需要一个同名的智能体访问伴随文件，具有匹配的稳定子功能 ID。使用契约记录 API、实际智能体入口点、策略、证据和缺口。将代表性源清单标记为 baseline / source-only；在声称完全访问覆盖之前枚举操作。复用 Paperclip 的 API、已准入工具和现有验证基础设施。地图更改后运行 node scripts/check-maps.mjs。不要在技能目录内创建地图或生成第二个运行时。

对于 Paperclip，按照地图契约所述为每个功能配方添加导航元数据。发现过程生成索引；不要在中央表中注册新功能或提交生成的目录。将审查/运行证据保留在 PR 或证据报告中，并使用 Git 进行源代码历史记录。

对于其他项目：创建 .agents/skills/verify-<app>/features/README.md 以及每个可识别的面向用户功能一个文件（从路由、命令、菜单或文档中开始，目标为前 3-5 个）。遵循 references/feature-map-example/ 中的形状，包含 README 索引和每个功能一个文件。每个文件从用户角度回答：功能是什么、如何到达、如何使用测试工具驱动它、什么可观察的最终状态证明它有效。四个 H2 是 Sub-features、How to get to it (user POV)、Driving it with <harness> 和 Gotchas。地图是仓库维护的验证来源；当地图列出其他入口点时，只驱动一个便利入口点的证明是不完整的。

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

端到端运行其自身指令一次：启动、诊断、驱动一个已映射功能（一个就够；地图的存在是为了后续运行可以覆盖其余部分）、采集证据、清理。清理后，确认证据仍存在于指定位置——吃掉证明的清理会使此步骤失败。修复失败之处，并在每次失败迭代后也运行生成的清理，这样损坏的尝试不会留下进程和端口。从未执行过的生成技能是草稿，不是交付物。

5. 提供维护循环

引导用户使用 /maintain-verification-skill 以在应用变化时保持地图诚实。仅在用户询问时建议节奏。

使用方式

该技能通过访谈代码仓库来收集信息，然后生成项目本地的验证技能文件。生成过程包括编写 SKILL.md、播种功能地图（对于 Paperclip 使用特定地图契约，对于其他项目创建 features 目录），并在交付前完整执行一次生成的技能以验证其可用性。

适用场景

适用于需要为项目建立脚本化验证流程的团队，特别是那些希望智能体能够独立驱动应用、验证功能并采集证据的场景。适用于各种语言、框架或平台的项目。

限制

  • 生成的内容基于仓库实际情况，如果检出代码无法构建或启动，需要先修复。
  • 对于 Paperclip 项目，需要遵循特定的地图契约和目录结构。
  • 生成的技能需要在交付前完整执行一次以验证其可用性。
  • 清理过程不能移除证据，证据必须保留在指定位置。
  • 关于收费、价格、平台等具体信息暂未提供。