Orchestrate code delivery from issue to verified acceptance

Runs coding work as an explicit state machine - intake, issue-gated, executing, review-loop, deploy-verify, accepted, escalated - that only reaches "accepted" once every acceptance criterion (the Definition of Done) has matching evidence, never just because code changed. It reads the issue to extract the task goal and DoD, refuses to implement anything while the issue is still in draft (gated by create-issue-gate logic), hands off implementation and local verification to closed-loop-delivery, then manages the PR review loop with fixed polling windows (wait 3 minutes, then 6, then 10, then stop waiting and process all visible comments together). If the DoD depends on runtime behavior, it deploys to dev by default and verifies against real logs, API responses, or Lambda behavior rather than assuming success. Before any completion claim it requires the verification-before-completion sub-skill to run - there is no "done" 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, when the work needs a structured handoff across implementation, review, deployment, and final verification, or when explicit stop conditions and escalation are wanted instead of silent partial completion.

It escalates rather than continuing when the DoD still fails after 2 full rounds, when missing secrets, permissions, or an external dependency blocks progress, when the task needs approval for a production action or a destructive operation, or when review instructions conflict and can't both be satisfied. It also always stops for human confirmation on prod/stage deploys beyond the agreed scope, destructive git or data operations, billing or security-posture changes, and missing user-provided acceptance criteria - it isn't meant to push through any of those on its own judgment.

Required inputs: an issue id or issue body, the issue's status, the acceptance criteria (DoD), and a target environment (defaulting to dev). Fixed defaults are 2 maximum iteration rounds and a PR-review polling schedule of 3, then 6, then 10 minutes.

Output is a status report with five fixed fields: Status (intake / executing / accepted / escalated), a pass/fail Acceptance Criteria checklist, Evidence (commands, logs, API results, or runtime proof), Open Risks, and Need Human Input naming the smallest next decision if blocked. A worked example request given is: "Take this issue and its acceptance criteria through implementation, validation, review, and a final evidence-backed verdict."

It composes with other skills rather than doing everything itself: it requires create-issue-gate, closed-loop-delivery, and verification-before-completion, and optionally uses deploy-dev, pr-watch, pr-review-autopilot, and git-ship.

Teams and agents running ticket-driven development who want a coding task's "done" to mean evidence-backed acceptance, not just a merged diff - with explicit, auditable stop points for production risk, missing inputs, or conflicting review feedback.