Automate Code Delivery to Definition of Done

This skill treats each task as incomplete until acceptance criteria are verified in evidence, not until code is merely changed - delivering against a Definition of Done (DoD) rather than against code diff size. It applies when a user gives a coding or fix task and expects end-to-end completion spanning code, tests, PR comments, dev deploy, and runtime checks, specifically to avoid repeated manual prompts like "now test" or "now deploy." It steps back for pure Q&A/explanations, production deploy requests without explicit human approval, and tasks blocked by missing secrets or account access that can't be inferred.

Before execution it defines the task goal, testable acceptance criteria, target environment (dev by default), and max iteration rounds (default 2) - requesting missing criteria once, then proposing a concrete default if the user doesn't supply them. It prefers checking an issue gate first: if the issue is ready and execution is allowed it continues, but a draft issue blocks the implementation/deploy/review loop until testable criteria exist. The default workflow is six steps: define the DoD as testable criteria, implement the minimal change needed, verify locally with focused then broader tests, run a review loop that fetches PR comments and fixes valid items, deploy to dev and verify runtime behavior with real evidence when it matters, and only report "done" once every DoD check passes - otherwise the loop continues until it passes or a stop condition is hit.

To avoid noisy polling it batches PR comment collection into three windows (3 minutes, then 6 minutes, then a final 10 minutes), processing all new comments per batch rather than re-polling after each single one, and aligns to CI completion boundaries instead of fixed rapid polling when CI is still running. It requires explicit user confirmation before production/staging deploys beyond agreed scope, destructive operations, billing or security-posture changes, missing secret values, or an ambiguous DoD that would materially change the outcome. It stops and escalates with a concise blocker report - what passed, what failed, the evidence, and the smallest decision needed - when the DoD still fails after the max rounds, an external dependency blocks progress, or review instructions conflict irreconcilably.

Use it for coding tasks that need genuine end-to-end verification across code, tests, review, and runtime behavior, not just a code change. Every completion claim must include the acceptance-criteria checklist with pass/fail status, the commands or tests run, runtime evidence, and PR status - it never claims success without that evidence.

Input is the task goal, acceptance criteria, target environment, and iteration limit. Output is either a verified completion report with evidence, or an escalation report naming what passed, what failed, and the smallest decision needed from the user.

It depends on create-issue-gate for a pre-execution readiness check, pulls PR comments and reviews from the code host for its batched polling windows, and aligns its polling to CI completion boundaries rather than fixed-interval checks.

Developers and agents running end-to-end coding tasks who need automatic test/deploy/re-check cycling against a real Definition of Done, with escalation on genuine blockers rather than silently claiming success.