closed-loop-delivery

# Closed-Loop Delivery ## Overview Treat each task as incomplete until acceptance criteria are verified in evidence, not until code is merely changed. Core rule: **deliver against DoD (Definition of Done), not against code diff size.** ## When to Use Use this skill when: - user gives a coding/fix task and expects end-to-end completion - task spans code + tests + PR comments + dev deploy + runtime checks - repeated manual prompts like "now test", "now deploy", "now re-check PR" should be avoided Do not use this skill for: - pure Q&A/explanations - prod deploy requests without explicit human approval - tasks blocked by missing secrets/account access that cannot be inferred ## Required Inputs Before execution, define these once: - task goal - acceptance criteria (DoD) - target environment (`dev` by default) - max iteration rounds (default `2`) If acceptance criteria are missing, request them once. If user does not provide, propose a concrete default and proceed. ## Issue Gate Dependency Before execution, prefer using `create-issue-gate`. - If issue status is `ready` and execution gate is `allowed`, continue. - If issue status is `draft`, do not execute implementation/deploy/review loops. - Require user-provided, testable acceptance criteria before starting execution. ## Default Workflow 1. **Define DoD** - Convert request into testable criteria. - Example: checkout task DoD = "checkout endpoint returns a valid, openable third-party payment URL in dev". 2. **I...