Python实现MIND特征提取：多模态医学图像配准的模态无关描述子
2026/9/17 2:03:19
用 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-skill，description声明它适用于"任何语言、框架、平台的仓库"，并列出触发方式：/create-verification-skill、"make a control skill for this repo"，或当项目没有脚本化方式证明 UI/CLI/服务行为时；disable-model-invocation: true：模型不能自发调用，只能由用户显式触发，确保生成动作始终有人把关。
二、第一步：面试仓库，而不是面试用户
技能的核心方法论是：只从代码库中找答案，只有代码无法观察到的内容才去问用户。面试围绕五个维度展开：
| 维度 | 要回答的问题 | 观察来源 |
|---|---|---|
| Surface | 用户实际接触的是什么？Web UI、CLI/TUI、桌面应用、API、移动端、库？一个仓库可能有多个，选出主表面并记下其余 | 源码结构、README |
| Run | 应用如何在本地启动？优先使用仓库自带的开发命令（package scripts、Makefile、README quickstart），并记录端口、环境变量、种子数据、认证方式 | 仓库文档化命令 |
| Drive | Agent 如何以编程方式与之交互？先找已有 harness（Playwright/Cypress 用例、expect 脚本、PTY 辅助、可 curl 的端点、调试端口），再退而求其次选通用方案：Web 与 Electron 用浏览器/CDP，CLI/TUI 用 tmux/PTY harness，服务用纯 HTTP | 现有测试与 harness |
| Observe | 能捕获什么证据？截图、终端转录、响应体、日志、退出码、数据库状态 | 应用的能力面 |
| Isolate | 两个实例能否并排运行（端口、数据目录、profile）？如果不能，要在生成的技能里明确写出：拒绝双驱动共享实例，好过弄坏用户正在使用的会话 | 启动参数与配置 |
面试中还埋了一条重要的纪律：如果 checkout 本身无法构建或启动，先修好（或精确上报），再生成技能——针对一个坏基线写的技能教会 Agent 错误的步骤。如果某个无关紧要的缺失资产阻塞了启动（比如 API 从不服务的静态目录、示例配置），生成的技能可以创建它，但要明确标注为"验证脚手架"，并在清理阶段移除。
三、第二步：生成技能——SKILL.md 的六大必需章节
生成产物写入.cursor/skills/verify-<app>/SKILL.md，带 YAML frontmatter：name: 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，并为每个可识别的用户面功能建一个文件（起步瞄准 3～5 个，从路由、命令、菜单或文档中识别）。形状遵循 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 标题 + 一段用户可见行为描述开头，然后严格按顺序使用四个 H2：
Sub-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 notes；Clear 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），仅供参考