Orchestrate code delivery from issue to verified acceptance

Acceptance Orchestrator drives a coding task end to end as a state machine - intake -> issue-gated -> executing -> review-loop -> deploy-verify -> accepted or escalated - that ends only once acceptance criteria are verified with evidence, never on "code changed" alone. It reads the issue and extracts the goal and definition of done at intake, then gates on create-issue-gate: if the issue is not ready or the execution gate is not allowed, it stops immediately and implements nothing while the issue stays draft. Implementation and local verification are handed off to closed-loop-delivery. PR review feedback is polled in three widening windows - 3 minutes, then 6, then 10 - after which it stops waiting and processes every visible comment together rather than polling indefinitely. If the definition of done depends on runtime behavior, it deploys only to dev by default and verifies with real logs, API, or Lambda behavior rather than assuming success. Before any completion claim, verification-before-completion is required - no success claim without fresh evidence.

Use it when a task already has an issue or clear acceptance criteria and should run end to end with minimal human re-intervention, needs structured handoff across implementation, review, deployment, and final verification, or needs explicit stop conditions instead of a silent partial completion. Required companion skills are create-issue-gate, closed-loop-delivery, and verification-before-completion; deploy-dev, pr-watch, pr-review-autopilot, and git-ship support it optionally. It moves to escalated rather than claiming success when the DoD still fails after 2 full rounds, a secret/permission/external dependency blocks progress, the task needs a production or destructive-operation approval, or review instructions conflict and cannot both be satisfied - and it always stops for human confirmation on prod/stage deploys beyond scope, destructive git or data operations, billing or security posture changes, or missing acceptance criteria.

Input is an issue ID or body, its status, the acceptance criteria (DoD), and a target environment (dev by default), with fixed defaults of 2 max iteration rounds and the 3m/6m/10m PR polling schedule. Output is a status report that always includes Status, a pass/fail Acceptance Criteria checklist, Evidence (commands, logs, API results, or runtime proof), Open Risks, and, if blocked, the smallest Need Human Input next decision - "done" is never reported unless Status is accepted.

create-issue-gate, closed-loop-delivery, verification-before-completion as required sub-skills; deploy-dev, pr-watch, pr-review-autopilot, and git-ship as optional supporting skills.

Teams that want a coding task driven from issue to verified acceptance with minimal hand-holding, but with explicit escalation instead of a task quietly reporting "done" on a partial or unverified result.