用途：为项目生成一个项目本地的验证技能（<skills-dir>/verify-<app>/），让智能体能够按用户路径真实驱动应用并留下证据。技能面向后续智能体编写，需能在冷启动、任务中途被直接阅读。
流程要点：
- 先解析 <skills-dir>。优先使用仓库已存在的项目级目录：.agents/skills/、.claude/skills/、.codex/skills/、.cursor/skills/、.pi/skills/，多个并存时选技能最多的一个；否则用中立的默认 .agents/skills/。若还存在第二套 harness 的技能目录，应以符号链接方式接入生成的技能而非复制，避免两者漂移；Windows 上则复制并在报告中说明会漂移。最终报告需写明解析出的路径。
- 通过阅读代码库而非询问用户来回答：界面（Web UI、CLI/TUI、桌面、API、移动、库等，选主要一种并记录其余）；本地启动方式（优先仓库自带的开发命令，如 package scripts、Makefile、README 快速上手，并记录端口、环境变量、种子数据、鉴权）；如何以程序方式驱动（优先已有 harness，如 Playwright/Cypress 规格、expect 脚本、PTY 辅助、可 curl 的端点、调试端口；否则选用通用方案：Web/Electron 用浏览器/CDP，CLI/TUI 用 tmux/PTY，服务用普通 HTTP）；可采集的证据（截图、终端记录、响应体、日志、退出码、数据库状态）；是否能并行运行两个实例（端口、数据目录、配置文件），不能则在生成的技能中明确说明。若检出无法构建或启动，应先修复或精确报告，再生成技能。
- 生成 <skills-dir>/verify-<app>/SKILL.md，含 YAML frontmatter（name 与描述需点名应用、界面与适用时机，缺少 frontmatter 技能不会注册），并包含：Launch（启动验证实例的准确命令、就绪判断、清理方式；短生命周期 CLI/TUI 则在隔离 PTY 或 tmux 中启动）；Doctor（只读检查，判断实例是否值得驱动）；Drive（真实的选择器与命令，优先 ARIA 标签、数据属性、提示串、路由路径等稳定句柄）；Evidence（采集什么、放在哪里，以及证据标准：走真实用户路径、同时记录动作与结果状态、验证副作用，仅在既有生产边界处使用 mock，并实际观察 dry-run 跳过了什么）；Cleanup（只清理本次启动的实例与临时状态，绝不按进程名杀进程，证据必须在清理后仍保留在指定位置）；Helpers（随技能提供的脚本需可执行并在正文中展示调用方式）。
- 播种功能地图：创建 <skills-dir>/verify-<app>/features/README.md 及每个用户可见功能一个文件（先做 3–5 个），按 references/feature-map-example/ 的形状，四个 H2 分别为 Sub-features、How to get to it (user POV)、Driving it with <harness>、Gotchas。
- 交付前必须端到端跑一遍：启动、doctor、驱动一个已映射功能、采集证据、清理，并确认证据仍在。失败需修复；每次失败迭代后也要运行生成的清理。未被执行过的技能只是草稿。
- 可指向 /maintain-verification-skill 维持地图准确性，仅在用户询问时建议节奏。
限制：资料未提供具体收费标准、支持平台清单之外的细节、性能或效果数据；实际生成内容取决于目标仓库的可观察事实，缺失部分需在技能中如实说明。