核心用法
verify-before-done 是一个纯 Markdown 文档型的 Agent 行为指导技能，旨在解决任务执行中的三大常见失效模式：过早声明成功、重复无效尝试、以及受阻时的模糊交接。该技能不提供可执行代码，而是通过六条核心规则塑造 Agent 的执行纪律：
1. 验证后再声明成功——在宣称任务完成前，优先进行直接验证（如运行测试、检查配置语法、发起真实请求等），而非依赖口头自信；
2. 无法验证时明确说明——当完整检查不可行时，清晰陈述已变更内容、已验证项、未验证项及剩余不确定性；
3. 识别重复模式陷阱——若两次尝试在本质上相似且未产生新证据，立即停止并切换策略（如查阅日志、阅读源码、隔离变量、缩小范围等）；
4. 询问用户前先自主调查——在请求用户信息前，先检查任务上下文、历史消息、文件、日志、文档、工具输出等是否已包含所需信息；
5. 适度修复相邻问题——解决主要问题后，简要检查紧密相关的潜在损坏，但避免范围蔓延；
6. 受阻时留下清晰交接——无法完全完成任务时，提供包含已验证事实、当前最窄问题陈述、已排除项及最佳下一步的紧凑交接。
该技能强调努力校准：简单低风险任务采用轻量检查，调试、代码变更、自动化、研究等正确性敏感任务则需更彻底的验证。
显著优点
- 零安全风险：纯文档设计，无可执行代码、无网络调用、无敏感数据操作，从根本上消除注入攻击、数据外泄等威胁向量；
- 执行质量提升：通过证据驱动的方法论，显著减少"应该已修复"这类虚假确认，提高交付可靠性；
- 抗 stuck 能力：内置的策略切换机制帮助 Agent 跳出无效循环，避免陷入重复同样错误的陷阱；
- 用户负担减轻：自主调查优先原则减少了对用户的无效提问，提升交互效率；
- 优雅降级：即使任务受阻，也能产出高价值的手交接文档，确保进度不丢失；
- 灵活适配：不强制改变个性或语气，可根据任务重要性动态调整验证深度，避免过度官僚化。
潜在缺点与局限性
- 无强制约束力：作为指导型技能，依赖 Agent 自主遵循，实际效果取决于实现层面的采纳程度；
- 验证深度判断主观："最轻量级有意义的检查"需要一定经验才能把握，新手可能过度或不足；
- 可能增加简单任务的摩擦：对于真正琐碎的任务，额外的验证步骤可能显得冗余；
- 交接质量依赖执行者：受阻时的交接质量最终取决于 Agent 的问题分析能力，技能本身无法保证；
- 不解决根本能力缺失：若 Agent 缺乏读取日志、分析源码等基础能力，策略切换建议无法落地。
适合的目标群体
- 可靠性敏感场景：生产环境代码变更、基础设施配置、自动化流水线等容错率低的任务；
- 复杂协作项目：需要清晰进度追踪和交接的长期、多人参与项目；
- 调试与排查任务：容易陷入"试试这个"循环的故障诊断场景；
- 高价值交付场景：客户演示、关键里程碑、审计准备等对质量有明确要求的节点；
- AI Agent 开发者：希望为其 Agent 系统嵌入系统化执行纪律的构建者。
使用风险
- 间接操作风险：技能建议的"验证"可能涉及运行测试、执行命令等操作，若在生产环境未加甄别地执行，可能造成意外影响；
- 版本漂移风险：未来版本若引入可执行代码，将改变安全属性，需关注更新日志；
- 过度验证风险：在高频率、低风险的重复任务中机械应用，可能降低整体效率；
- 虚假安全感：遵循技能形式（如使用了"验证"话术）但未实质执行验证，可能反而掩盖问题。
建议在关键环境中结合权限隔离和变更评审机制使用，确保验证操作本身的可控性。