当编码任务需要从问题接收端到端驱动,通过实现、审查、部署和验收验证,且需要最少的人工干预时使用此技能。技能概述acceptance-orchestrator 技能是一个端到端的任务编排技能,它将编码工作作为状态机进行编排,只有在验收标准得到证据验证或任务明确升级时才结束。核心规则是:不要优化代码更改,而是优化DoD(完成定义)证明。下载地址:https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/acceptance-orchestrator主要功能状态机编排: 将编码工作作为状态机进行管理,确保任务从接收到验收的完整流程端到端驱动: 从问题接收、实现、审查、部署到验收验证的全流程自动化最小人工干预: 减少人工介入,提高自动化程度证据验证: 在声称完成之前需要验证证据,确保任务真正完成升级机制: 当任务无法完成时提供明确的升级路径触发条件在以下情况下应该调用此技能:任务已经有问题或明确的验收标准,应该端到端运行且最少人工干预需要在实现、审查、部署和最终验证之间进行结构化交接需要明确的停止条件和升级机制,而不是静默的部分完成使用场景场景1: 端到端任务执行当一个编码任务需要从问题接收开始,经过实现、审查、部署,最终到验收验证的完整流程时,使用此技能可以确保每个阶段都有明确的输出和验证。场景2: 自动化工作流当需要减少人工干预,实现高度自动化的开发流程时,此技能可以管理整个生命周期,只在必要时请求人工确认。处理过程1. 接收阶段(Intake)读取问题并提取任务目标和DoD(完成定义)。2. 问题门控(Issue Gate)使用create-issue-gate逻辑。如果问题不是ready状态或执行门控不允许,立即停止。不要在问题仍为draft状态时实现任何内容。3. 执行阶段(Execute)移交给closed-loop-delivery进行实现和本地验证。4. 审查循环(Review Loop)如果PR反馈相关,批量轮询窗口为:等待3分钟,然后6分钟,然后10分钟。在10分钟轮次后,停止等待并一起处理所有可见的评论。5. 部署和运行时验证如果DoD依赖于运行时行为,默认仅部署到dev环境。使用真实的日志/API/Lambda行为进行验证,而不是假设。6. 完成门控在任何声称完成之前,需要verification-before-completion。没有新鲜证据就不能声称成功。输入要求使用此技能时,需要提供:问题ID或问题正文问题状态验收标准(DoD)目标环境(dev默认)输出说明技能将提供:状态: intake / executing / accepted / escalated验收标准: 通过/失败检查清单证据: 命令、日志、API结果或运行时证明开放风险: 任何仍然不确定的内容需要人工输入: 如果被阻塞,最小的下一步决策状态机intake: 接收阶段issue-gated: 问题门控executing: 执行中review-loop: 审查循环deploy-verify: 部署验证accepted: 已接受escalated: 已升级停止条件移动到accepted:只有当每个验收标准都有匹配的证据时。移动到escalated:当发生以下任何情况时:DoD在2个完整轮次后仍然失败缺少密钥/权限/外部依赖项阻碍进度任务需要生产操作或破坏性操作批准审查指令冲突且无法同时满足人工门控始终在以下情况下停止等待人工确认:超出约定范围的生产/预发布部署破坏性的git/数据操作计费或安全态势更改缺少用户提供的验收标准所需子技能必需: create-issue-gate, closed-loop-delivery, verification-before-completion可选: deploy-dev, pr-watch, pr-review-autopilot, git-ship最佳实践优化DoD证明: 不要优化代码更改,而是优化DoD证明明确停止条件: 确保每个任务都有明确的停止条件证据驱动: 在声称完成之前必须有新鲜证据升级机制: 当任务无法完成时及时升级固定默认值最大迭代轮次 2PR审查轮询 3分钟 - 6分钟 - 10分钟注意事项仅在任务明确匹配上述范围时使用此技能不要将输出作为环境特定验证、测试或专家审查的替代品如果缺少所需的输入、权限、安全边界或成功标准,请停止并请求澄清