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. Implement minimal change

   • Keep scope tight to task goal.

3. Verify locally

   • Run focused tests first, then broader checks if needed.