用途：当任务已有 issue 或明确验收标准，并希望以最少人工干预端到端跑完实现、评审、部署与最终验证时使用。它强调结构化交接、明确的停止条件与升级机制，而非静默的部分完成。
主要能力：以状态机组织流程，状态包括 intake、issue-gated、executing、review-loop、deploy-verify、accepted、escalated。依赖三个子技能：create-issue-gate、closed-loop-delivery、verification-before-completion。部署与 PR 监控属于项目特定能力，不随技能捆绑；需使用仓库实际的部署与评审流程，旧名称 deploy-dev、pr-watch、pr-review-autopilot、git-ship 在 AAS 中不可用。
使用方式：需提供 issue id 或 issue body、issue 状态、验收标准（DoD）、目标环境（默认 dev）。固定默认值：最大迭代轮数 2；PR 评审轮询为 3m -> 6m -> 10m，10m 后停止等待并统一处理可见评论。流程为：读取 issue 提取目标与 DoD；经 issue gate，若未就绪或不允许执行则立即停止，草稿状态不得实现；交给 closed-loop-delivery 实现与本地验证；进入评审循环；若 DoD 依赖运行时行为，在明确授权的环境验证，dev 标签不等于部署许可，需检查影响并走项目部署门；完成前必须经 verification-before-completion，无新证据不得声称成功。
停止条件：每条验收标准都有匹配证据才进入 accepted；出现以下情况进入 escalated：两轮完整迭代后 DoD 仍失败、缺少密钥/权限/外部依赖阻塞、需要生产操作或破坏性操作审批、评审指令冲突无法同时满足。以下情况必须人工确认：超出约定范围的 prod/stage 部署、破坏性 git/数据操作、计费或安全态势变更、缺少用户提供的验收标准。
输出契约：报告须含 Status、Acceptance Criteria 通过/失败清单、Evidence（命令、日志、API 结果或运行时证明）、Open Risks、Need Human Input。状态非 accepted 不得报告“done”。
限制：仅在任务明确匹配上述范围时使用；输出不能替代环境特定验证、测试或专家评审；缺少必要输入、权限、安全边界或成功标准时应停止并请求澄清。