用 create-verification-skill 为任意仓库生成可执行的验证技能（verify skill）

用 create-verification-skill 为任意仓库生成可执行的验证技能verify skill【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins导读pstack 插件中的 create-verification-skill 是一个针对 Agent 的元技能meta-skill它不直接驱动你的应用而是为仓库生成一个项目本地的验证技能.cursor/skills/verify-app/把像用户一样驱动真实应用并留下证据这件事脚本化、可重复化。读完本文你将掌握该技能面试仓库的五个维度、生成的 SKILL.md 六大必需章节、feature map 的四段式结构与实战写法以及生成后必须实跑一遍的交付标准文中还结合 pstack 与 cursor-team-kit 中的 maintain-verification-skill、control-ui、control-cli 等配套技能给出可直接套用的落地方案。一、它解决什么问题让验证从口头承诺变成脚本化交付物能编译不是证据。pstack 的核心验证原则 prove-it-works 要求 Agent 在宣称完成前针对真实产物做验证——运行功能、读取真实值、检查 diff——而不是依赖代理指标、自我报告或它能编译。pstack 指南的验证章节 明确指出Agent 需要一条脚本化的路径来驱动你的应用如果项目没有就跑/create-verification-skill。该技能的价值主张很明确每个严肃项目都需要一条脚本化路径来启动真实应用、像用户一样操作一个功能、并捕获证据。它生成的不是给人看的文档而是给下一个 Agent看的指令——那个 Agent 会在任务中途、冷启动地读取它而且从未见过这个应用。因此生成物必须具体、精确、可复现不允许留占位符。技能的前置元数据SKILL.md 的 YAML frontmatter说明name: create-verification-skilldescription声明它适用于任何语言、框架、平台的仓库并列出触发方式/create-verification-skill、make a control skill for this repo或当项目没有脚本化方式证明 UI/CLI/服务行为时disable-model-invocation: true模型不能自发调用只能由用户显式触发确保生成动作始终有人把关。二、第一步面试仓库而不是面试用户技能的核心方法论是只从代码库中找答案只有代码无法观察到的内容才去问用户。面试围绕五个维度展开维度要回答的问题观察来源Surface用户实际接触的是什么Web UI、CLI/TUI、桌面应用、API、移动端、库一个仓库可能有多个选出主表面并记下其余源码结构、READMERun应用如何在本地启动优先使用仓库自带的开发命令package scripts、Makefile、README quickstart并记录端口、环境变量、种子数据、认证方式仓库文档化命令DriveAgent 如何以编程方式与之交互先找已有 harnessPlaywright/Cypress 用例、expect 脚本、PTY 辅助、可 curl 的端点、调试端口再退而求其次选通用方案Web 与 Electron 用浏览器/CDPCLI/TUI 用 tmux/PTY harness服务用纯 HTTP现有测试与 harnessObserve能捕获什么证据截图、终端转录、响应体、日志、退出码、数据库状态应用的能力面Isolate两个实例能否并排运行端口、数据目录、profile如果不能要在生成的技能里明确写出拒绝双驱动共享实例好过弄坏用户正在使用的会话启动参数与配置面试中还埋了一条重要的纪律如果 checkout 本身无法构建或启动先修好或精确上报再生成技能——针对一个坏基线写的技能教会 Agent 错误的步骤。如果某个无关紧要的缺失资产阻塞了启动比如 API 从不服务的静态目录、示例配置生成的技能可以创建它但要明确标注为验证脚手架并在清理阶段移除。三、第二步生成技能——SKILL.md 的六大必需章节生成产物写入.cursor/skills/verify-app/SKILL.md带 YAML frontmattername: verify-app加一段description要指名应用、表面、何时使用——没有 frontmatter技能永远不会被注册。正文六个章节每一节都必须以面试的实际发现为地基Launch启动启动应用用于验证的精确命令以及如何判断它已就绪日志行、端口响应、出现提示符。必须包含 teardown。对短命 CLI/TUI 没有常驻服务器Launch 意味着先构建二进制或安装依赖一次然后每次驱动都在独立的 PTY 或 tmux 会话中启动。Doctor体检一个只读检查回答这个实例值得驱动吗——进程在不在、版本/构建对不对、端口是不是我们占的、认证是否有效。任何看起来不对劲的时候Agent 第一步就运行它。Drive驱动来自本仓库的真实选择器/命令的 harness 配方不是示例。优先用稳定句柄ARIA 标签、data 属性、提示字符串、路由路径而不是坐标和 Tab 顺序。Evidence证据为证明捕获什么、放到哪里。并写明证明标准走真实用户路径而不是内部 setter 或仅测试端点同时捕获动作与结果状态而非只有最终画面验证副作用写出的文件、插入的行、发出的消息与可见结果并重仅在生产边界已隔离外部系统处使用 mock。当安全路径是 dry-run 或测试模式时通过观察文件、网络、git refs验证它实际跳过了什么而不是信任它的名字——有些 dry-run 仍会碰网络或打开浏览器。Cleanup清理如何拆除本次运行创建的实例。绝不按进程名杀进程只杀你自己启动的。清理移除实例与临时状态但绝不碰证据证明产物在 teardown 后依然存在位于技能点名的位置。Helpers辅助脚本技能附带的任何脚本都必须是可执行的且调用方式要写在技能正文里——需要读者逆向工程的 helper 就不是 helper。四、第三步播种 feature map——仓库维护中的验证源头生成器创建.cursor/skills/verify-app/features/README.md并为每个可识别的用户面功能建一个文件起步瞄准 35 个从路由、命令、菜单或文档中识别。形状遵循 references/feature-map-example/ 中的示例。4.1 feature map 的 README基线、约定与入口契约仓库附带的 示例 README 展示了 map 应该承载哪些元信息Baseline preconditions基线前置条件每个配方都从同一基线出发。示例用NOTES_DATA_DIR/tmp/notes-verify-$RUN_ID保证并发运行不共享状态用可丢弃数据目录种子化Quarterly plan与Grocery list两篇笔记并规定绝不驱动非本次验证启动的实例。Driving conventions驱动约定优先 ARIA role 与可访问名称而非 CSS 选择器把每个命令当字面量对待保持引号名称与 flag 不变浏览器动作经control-notes browser运行终端动作经control-notes cli -- command运行变更后恢复种子数据清理时不移除证明产物。Proof and skip reporting证明与跳过报告捕获用户动作与结果状态而非仅最终画面UI 证明含 ARIA snapshot 与带应用标识的截图CLI 证明含命令、stdout、stderr 与退出码变更类证明含一次只读的二次视图每个产物都记录 feature ID 与入口点未达路径要上报尝试过的命令与未满足的前置条件不把通过另一条路径验证当作跳过入口点的验证。Feature entry contract功能条目契约每个功能文件以 H1 标题 一段用户可见行为描述开头然后严格按顺序使用四个 H2Sub-features、How to get to it (user POV)、Driving it with harness、Gotchas。实现细节不进 map——只写用户路径、稳定句柄、所需状态、命令与可观察证明。4.2 功能文件的四段式结构以 create-note.md 为例create-note.md 演示了如何把新建笔记拆成可验证的原子行为Sub-features短 ID 列表每条行为一行——create-open从每个浏览器入口打开空白编辑器、create-save持久化标题与正文、create-cancel丢弃未完成的浏览器草稿、create-cli从终端创建同形状笔记。How to get to it (user POV)列出每个用户入口——浏览器工具栏的New note按钮、焦点不在可编辑字段时按n、终端运行notes create --title title --body body。Driving it with control-notes以Preconditions:开头Notes 健康、不存在Release checklist笔记、doctor 报告预期 URL 与一次性数据目录然后用成对的标签式条目把用户动作 ↔ 精确命令 ↔ 可观察结果一一对应control-notes browser click --role button --name New note→ 名为Note editor的表单出现且焦点在Title文本框--role textbox --name Title --value Release checklist填充 →Save note按钮启用保存后状态Note saved出现且标题栏读作Release checklist确认持久化需从All notes重新打开该笔记并断言两个已存值取消草稿后断言笔记列表没有Discard me链接CLI 入口断言退出码0且 stdout 含新笔记 ID 与标题最后的 Proof 步骤用browser snapshot --aria与browser screenshot落盘到artifacts/create-note/。Gotchas焦点陷阱文本框聚焦时按n是输入字符而非打开编辑器、保存时标题会被 trim断言渲染后的标题而非草稿输入值、保存状态本身不是充分证明必须从列表重新打开、夹具清理要删除测试笔记但保留证明产物。4.3 多入口功能怎么写以 search.md 为例search.md 覆盖更复杂的行为面search-open/search-match/search-open-result/search-empty/search-clear/search-cli六个子功能浏览器工具栏按钮、/快捷键、终端命令三个入口。它示范了几个进阶要点键盘入口的验证control-notes browser press --key /后断言搜索对话框出现且页面没有插入斜杠——证明快捷键被正确拦截。标题匹配与正文匹配的区分quarterly命中标题budget命中正文断言Quarterly plan仍可见并带正文匹配摘要。空状态与清除volcano无匹配 → 状态No matching notesClear search→ searchbox 为空且Recent notes区域回归。CLI 的稳定断言control-notes cli -- notes search quarterly --format json断言退出码0与单个对象搜索缺失值断言 stdout 为[]——注意示例 Gotchas 明确提醒CLI 默认人类可读输出用--format json做稳定断言。debounce 处理结果在短 debounce 后更新。等待结果列表或空状态而不是固定 sleep——这是 control-cli 中优先确定性等待而非 sleep原则在 map 层面的体现。状态污染打开结果会改变浏览器状态。证明下一个查询前重新打开搜索。五、第四步交付前先自证——生成但从未执行过的技能只是草稿这是整个技能最硬核的验收纪律在交付前把生成的技能自己的指令端到端跑一遍——launch、doctor、驱动一个映射的功能一个就够map 存在的意义就是后续运行覆盖其余、捕获证据、清理。清理后确认证据仍存在于点名位置——吞掉证明的清理即失败。修掉失败点并且每次失败迭代后也要跑生成的清理避免失败尝试残留进程和端口。也就是说生成但从未执行过的技能是草稿不是交付物。pstack 指南 也强调如果自证失败不要使用输出。这一节把可运行性从抽象承诺变成生成流程中的硬性关卡。六、第五步交接维护闭环技能最后一步是引导用户到 /maintain-verification-skill——功能地图在应用变更的那一刻就开始腐烂维护技能是它的保养循环。其核心机制也是理解生成物如何长期存活的钥匙单元是 feature 而非句子每个功能文件都要有源码覆盖每个功能都要实跑但不强求逐条 bullet 的终端化验证。三种结局clean全覆盖、无可交付、changed一个 PR 交付有证明的文档/harness/map 修正、blocked明确说出阻塞点。编辑范围铁律只改验证技能自己的目录SKILL.md、features/、它拥有的 harness 脚本绝不改产品代码——map 描述的行为应用已不提供要么是文档漂移修 map要么是产品回归上报不用文档掩盖。实跑阶段的三条不变量绝不驱动上次有意外后未体检过的实例doctor 先行、失败后复检、UI 卡死则重置或重启已捕获证据在每次清理后仍存活到点名位置检查而非假设任何驱动启动的东西不活得比它的用途更久共享实例清残留而非清实例。triage 分流用户 POV 描述错/缺 → 文档漂移修之行为正常但 harness 驱不动 → harness 缺口修之沿用脚本可执行、调用方式写在技能正文的 helpers 规则应用行为真的坏了 → 产品缺口记录给用户不塞进本 PR。两条技能构成完整生命周期create-verification-skill负责从零生成maintain-verification-skill负责持续保鲜且后者明确在技能缺少时指向/create-verification-skill而不是凭空发明目标。七、配套 harness 参考Drive 章节可落地的通用配方生成的 Drive 章节优先复用仓库现有 harness只有没有时才选通用配方。仓库中 cursor-team-kit 插件的两个技能正是这类通用配方的权威参考control-ui面向 Web/IDE/Electron 的浏览器/CDP harness。先复用仓库自带的 Playwright/browser/Electron harness否则围绕 dev server 或 Chromium 调试端口组装临时 harness。选页面用稳定应用标记根选择器、landmark、产品 contenteditable="false">【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考