关于 iterate-until-verified
供 Agent 用于基于证据反复执行和验证任务的技能。它保留原始任务,将质量目标转为验收门槛,分离实现与审查,并持续迭代直至验证通过或遇到阻碍。
主要功能
- 01保留原始任务约定
- 02将目标转化为验收门槛
- 03拆分工作流并分配负责人
- 04分离实现与审查
- 05依据证据和测试结果迭代
- 06报告阻碍与未知事项
适用场景
- 01按明确完成标准执行任务
- 02根据未通过的验收检查修改成果
- 03委派独立工作并避免编辑冲突
- 04返回可复用提示词而非直接执行
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ mengto/ skills --skill iterate-until-verified安装后在 Claude Code 中输入/iterate-until-verified确认已加载。
附带文件agents/openai.yamlREFERENCES.md
详细介绍
迭代直至验证通过
保留任务。强化围绕任务的流程。
选择模式
- **执行:**按照以下工作流完成原始任务。默认使用此模式。
- **编写:**当用户要求改进提示词而非完成任务时,返回一个可复用的提示词包装器。将原始任务完整保留在包装器中,并以其为准。
不要在未说明的情况下,从编写提示词切换为执行任务。
1. 锁定原始任务
提取:
- 目标和交付物
- 受众和使用场景
- 提供的输入和参考资料
- 约束、工具、格式和排除项
- 获准采取的操作和受保护的边界
- 明确的完成定义
将这些视为任务契约。不要替换主题、臆造要求、放宽约束、扩大权限,也不要让验证方法取代交付物。
只有当缺失的答案会实质性改变工作,且无法安全地自行查明时,才提出问题。否则,说明一个合理的假设并继续。
2. 将目标转化为关卡
将 perfect、best、professional、production-ready 或 AAA 等词转化为可观察的检查项。仅选择与任务相关的维度:
- 正确性和事实准确性
- 对请求的完整满足程度
- 工艺、清晰度和受众适配度
- 可用性和无障碍性
- 稳健性、边缘情况和回归安全性
- 性能、安全性或合规性
- 与所提供基准在视觉、编辑或技术方面的一致性
建立一份精简的验收矩阵:
| 关卡 | 验证方法 | 通过条件 | 证据 |
|---|---|---|---|
| 相关质量维度 | 测试、检查、比较或回读 | 可观察的二元条件 | 命令、来源、截图、输出或成果物 |
优先使用通过/失败条件,而非模糊的评分。强烈的正面反应(如“惊艳”)可以作为有用信号,但绝不能成为唯一关卡。
3. 拆分并分配
将任务拆分为最小且有意义的工作流,并明确其负责人、输入、输出和集成边界。
- 只拆分真正独立的工作流。
- 将相互关联的编辑交由同一负责人,避免并行修改冲突。
- 向每位执行者提供原始任务契约和其所需的上下文。
- 要求每位执行者返回成果物或证据,而非仅表达信心。
- 指定一位集成人员负责跨工作流的一致性和回归检查。
在子 Agent 或委派执行者可用、获准且有帮助时,使用它们。否则,按顺序执行各工作流,同时保留相同的职责边界。
4. 将制作与评审分开
不要让实施者成为自己成果的唯一审批者。
向验证者提供:
- 原始任务契约
- 验收矩阵
- 候选成果物
- 相关基准或源材料
除非验证者需要这些信息来复现检查,否则不要提供实施者的理由说明和自我评估。要求验证者优先查找失败项、引用证据、驳回缺乏依据的主张,并逐项返回关卡判定。
进行盲法比较时:
- 在可行的情况下,对候选项进行匿名化并随机排序
- 在相同条件下比较同类候选项
- 让评估者不知道作者或候选项的身份,但不隐瞒任务或评分标准
- 如果仍有明显的身份线索,就不要称这种比较为盲法比较
5. 让验证方式与工作相匹配
使用可用的最有力验证方式:
- **代码:**针对性测试、类型检查、构建、代码检查、安全检查、运行时行为和回归测试。
- **视觉工作:**在相关尺寸下检查渲染结果、交互、可访问性,并与可访问的参考进行并排比较。
- **研究或分析:**一手资料、可复现的计算、引文检查和矛盾信息检索。
- **写作:**事实核查、简要覆盖情况、受众适配度、结构,以及参照代表性资料进行编辑审阅。
- **计划或决策:**约束覆盖情况、依赖项检查、失败场景、可行性和明确的权衡。
- **外部操作:**先准确确认目标,再在操作后回读确认。
绝不要用自我评价代替证据。绝不要编造基准、来源、测试结果、截图或盲评结论。
6. 循环执行
重复以下步骤:
- 生成或改进候选结果。
- 运行所有适用的门禁。
- 根据证据记录
pass、fail或blocked。 - 将每项失败转交给负责的工作流。
- 进行能够解决证据所指问题的最小修改。
- 重新运行失败的门禁和所有受影响的回归门禁。
- 仅整合已验证的工作。
只要必需门禁仍未通过,且在安全范围内的操作能够取得实质进展,就继续执行。反复失败后,不要继续采用相同方法;应更换方法或报告阻碍。
7. 如实停止
只有满足以下条件时才能完成:
- 所有必需门禁均已通过
- 整合后的结果仍符合原始任务要求
- 已检查与更改内容相关的回归问题
- 最终声明有证据支持
- 已披露剩余的未知事项
如果某项必需门禁依赖缺失的访问权限、不可用的输入、额外授权或不可行的约束,则应以受阻状态停止。明确说明具体阻碍和所需的最小后续操作。不要为了宣布成功而降低门禁标准。
Compose 模式模板
返回增强版提示词时,请采用以下格式:
Use an iterative execution-and-verification workflow around the authoritative task below.
AUTHORITATIVE TASK
<preserve the user's original task here without changing its subject, deliverables, or constraints>
PROCESS
1. Extract the task contract and convert subjective quality language into observable acceptance gates.
2. Decompose independent workstreams and fan them out when delegation is useful and permitted.
3. Keep one integrator responsible for consistency.
4. Assign an independent verifier that sees the task, rubric, candidate, and references—but not the implementer's self-assessment.
5. Verify with task-appropriate evidence. Use anonymized side-by-side comparison when a real comparable benchmark exists.
6. Route failed gates back to the responsible workstream, revise, and re-check affected regressions.
7. Do not finish until every required gate passes or a concrete blocker is proven.
FINAL RESPONSE
Return the deliverable, a concise gate-by-gate evidence summary, and anything still unverified. Do not claim checks that were not run.
根据任务调整流程。除非适用于当前任务,否则不要照搬其他提示词中的特定领域工具、基准或质量声明。
完成检查
- 原始任务仍具有最高优先级。
- 主观目标已转化为可观察的门禁。
- 已将独立工作分开,且没有造成编辑冲突。
- 制作和评判工作由不同角色负责。
- 基准真实、可比较,并且标注准确。
- 失败的门禁推动了修改。
- 最终声明与收集到的证据一致。