用途
每个严肃的项目都需要一种脚本化的方式来驱动真实应用并证明其行为：启动它、像用户一样操作某个功能、并采集证据。该技能把这一能力生成为一个项目本地的技能，路径为 .agents/skills/verify-<app>/，并针对具体仓库进行定制。生成器的输出是写给下一个智能体看的，而不是写给人看的：它会被一个从未见过该应用的智能体在任务中途冷启动阅读。
主要能力
1. 访谈仓库而非用户
从代码库中回答以下问题，只向用户询问无法观察到的事项：
- 交互面（Surface）：用户实际接触的是什么？Web UI、CLI/TUI、桌面应用、API、移动应用还是库？一个仓库可能有多个，选择主要的一个并记录其余。
- 运行（Run）：应用如何在本地启动？优先使用仓库自身文档化的开发命令（package scripts、Makefile、README 快速开始）。记录端口、环境变量、种子数据、认证。
- 驱动（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. 播种特性地图
创建 .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，以便在应用变化时保持地图诚实。仅在用户询问时建议节奏。
使用方式
该技能通过访谈代码仓库来发现应用的真实交互面，选择通过 proof-orchestrator 的证明路径，并通过 model-capability-router 尊重所选模型和努力程度。原生验证运行器是获得验证结果的必要条件。如果装置或启动缺失，保留项目并报告阻塞。生成过程绝不安装全局技能、发布产物、打开 PR、按进程名杀进程或更改产品代码。特性地图引用有意保留可复现的上游控制笔记命令；在使用前将其适配为目标仓库中观察到的具体命令。仅当 cursor-control-ui 和 cursor-control-cli 技能已安装且适用时，才将浏览器/Electron/Web 操作映射到 cursor-control-ui，将 CLI/TUI 操作映射到 cursor-control-cli；否则记录确切的交互面缺口。有界 CLI 夹具使用独立子进程，运行语法/版本/健康 Doctor 检查，驱动每个已映射功能，捕获 stdout/stderr/退出码以及常规文件副作用，仅清理声明的应用状态，并仅写入显式的项目本地技能树。一个单独的一次性本地 Web 夹具通过原生 Codex 应用内浏览器驱动，带有可访问性树和截图证据；这仍不声称生产/实时目标或原生主机验证。
适用场景
适用于需要为项目建立可重复、可证明的验证流程的场景，尤其是希望智能体能够像真实用户一样驱动应用并采集证据的仓库。适合 Web UI、CLI/TUI、桌面应用、API、移动应用或库等多种交互面。
限制
- 原生验证运行器是获得验证结果的必要条件；如果装置或启动缺失，保留项目并报告阻塞。
- 生成过程绝不安装全局技能、发布产物、打开 PR、按进程名杀进程或更改产品代码。
- 仅当 cursor-control-ui 和 cursor-control-cli 技能已安装且适用时，才进行相应映射；否则记录确切的交互面缺口。
- 一次性本地 Web 夹具的驱动不声称生产/实时目标或原生主机验证。
- 如果检出代码无法按原样构建或启动，需先修复或精确报告再生成。
- 关于收费、价格、平台支持范围等具体信息暂未提供。