一句话

给 /create-verification-skill 生成的验证技能和 feature map 做巡检：每个功能一个只读子代理对源码，再跑一次真机全功能驱动，最多产出一个已验证修正的 PR。

何时用

• 适合：feature map 随 app 变化开始失真；guide 建议至少每天跑一次，最好交给定时 automation。
• 不适合：首次生成验证技能（用 pstack-create-verification-skill）。

怎么用

/maintain-verification-skill

1. 定位 .cursor/skills/verify-*/ 下有 launch/drive 和 feature map 的技能；没有就指向 create，有多个先问。
2. 索引体检：地图 README 的缺失、多余、死链接先修。
3. Source wave：每个功能文件一个只读子代理，从源码讲功能并标疑似漂移，返回一条真机验证 recipe。
4. Live pass：协调者独占驱动，按技能自己的 launch 模型跑每个功能至少一次；doctor 先行、证据存活、不留残余进程。
5. Triage：描述错漏修地图，驱动不了修 harness（修复后真机重验），app 行为坏了记为 product gap 只报告不遮掩。
6. 只在有已验证修正时出一个 PR，限验证技能目录内；否则 clean 或 blocked 如实汇报。

产出

• 三种结局之一：clean / changed（一个 PR）/ blocked，外加不提交的 run notes。

要点与坑

• 真机 pass 是强制的，源码看着干净也得跑；product regression 绝不靠改文档粉饰。
• 编辑范围只有验证技能自己的目录；碰不到的功能要有具体前置条件才算 verified-unreachable。
• 依赖项目里的 verify 技能；在 Devin CLI 可借鉴「源码波加真机波」的巡检结构。

关联

• 上游：pstack-create-verification-skill · 同类：pstack-maintain-formal-verification-skill
• 所属：00-pstack-概览