---

name: acceptance-orchestrator description: 当编码任务应从问题接收到实现、审查、部署和验收验证端到端驱动，且最少人工重新干预时使用。 risk: safe source: community date_added: "2026-03-12"

验收编排器

概述

将编码工作编排为状态机，仅在验收标准通过证据验证或任务被明确升级时结束。

核心规则：不要优化"代码已更改"；优化"DoD 已证明"。

何时使用

• 任务已有 issue 或明确的验收标准，应以最少人工重新干预端到端运行。
• 你需要跨实现、审查、部署和最终验证的结构化交接。
• 你想要明确的停止条件和升级，而非静默的部分完成。

所需子技能

• create-issue-gate
• closed-loop-delivery
• verification-before-completion

可选支持技能：

• deploy-dev
• pr-watch
• pr-review-autopilot
• git-ship

输入

需要这些输入：

• issue id 或 issue 正文
• issue 状态
• 验收标准（DoD）
• 目标环境（默认 dev）

固定默认值：

• 最大迭代轮数 = 2
• PR 审查轮询 = 3m -> 6m -> 10m

状态机

• intake（接收）
• issue-gated（issue 门控）
• executing（执行中）
• review-loop（审查循环）
• deploy-verify（部署验证）
• accepted（已接受）
• escalated（已升级）

工作流

1. 接收

   • 阅读 issue 并提取任务目标 + DoD。

2. Issue 门控

   • 使用 create-issue-gate 逻辑。
   • 如果 issue 不是 ready 或执行门控不是 allowed，立即停止。
   • issue 仍为 draft 时不要实现任何东西。

3. 执行

   • 交给 closed-loop-delivery 进行实现和本地验证。

4. 审查循环

   • 如果 PR 反馈相关，批量轮询窗口为：
     • 等待 3m
     • 然后 6m
     • 然后 10m
   • 10m 轮次后，停止等待并一起处理所有可见评论。

5. 部署和运行时验证

   • 如果 DoD 依赖运行时行为，默认仅部署到 dev。
   • 用真实日志/API/Lambda 行为验证，而非假设。

6. 完成门控

   • 在任何完成声明之前，需要 verification-before-completion。
   • 没有新鲜证据不做成功声明。

停止条件

仅当每个验收标准都有匹配证据时移至 accepted。

当以下任何情况发生时移至 escalated：

• 2 轮完整迭代后 DoD 仍然失败
• 缺少密钥/权限/外部依赖阻碍进展
• 任务需要生产操作或破坏性操作批准
• 审查指令冲突且无法同时满足

人工门控

始终在以下情况停下等待人工确认：

• 超出约定范围的 prod/stage 部署
• 破坏性 git/数据操作
• 计费或安全态势变更
• 缺少用户提供的验收标准

输出契约

报告状态时，始终包含：

• Status：intake / executing / accepted / escalated
• Acceptance Criteria：通过/失败清单
• Evidence：命令、日志、API 结果或运行时证明
• Open Risks：任何仍不确定的事项
• Need Human Input：如果被阻塞，最小的下一个决策

除非状态为 accepted，否则不要报告"完成"。

限制

• 仅在任务明确匹配上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少所需的输入、权限、安全边界或成功标准，请停下来寻求澄清。