sickn33/antigravity-awesome-skills/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)
• review cadence/budget when requested; a default review cadence is not a task-completion limit

If acceptance criteria are missing, request them once. If user does not provide, propose a concrete default and proceed.

Issue Gate Dependency

If the project already uses create-issue-gate, respect its current contract; otherwise derive acceptance criteria from the authorized task without inventing a mandatory issue.

• If issue status is ready and execution gate is allowed, continue.
• A real project-required draft gate can block dependent actions; it does not forbid independent discovery or already-authorized work under a different applicable workflow.
• Use available task context to formulate testable criteria; clarify only when a missing decision materially changes the outcome.

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".

1. Implement minimal change

• Keep scope tight to task goal.

1. Verify locally

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

1. Review loop

• Fetch PR comments/reviews.
• Classify valid vs non-actionable.
• Fix valid items, re-run verification.

1. Dev deploy + runtime verification

• Deploy only to an already-authorized dev target when runtime behavior matters; otherwise prepare and verify the concrete candidate locally.
• Verify via real API/Lambda/log evidence against DoD.

1. Completion decision

• Only report "done" when all DoD checks pass.
• Otherwise continue loop until pass or stop condition.

PR Comment Polling Policy

Avoid noisy short polling by default. Use batched windows:

• Round 1: wait 3m, collect delta comments/reviews
• Round 2: wait 6m, collect delta again
• Final round: wait 10m, collect all remaining visible comments/reviews

At each round:

• process all new comments in one batch
• avoid immediate re-poll after each single comment
• after the 10m round, stop waiting and proceed with all comments visible at that point

If CI is still running, align polling to check completion boundaries instead of fixed rapid polling.

Human Gate Rules (Must Ask)

Require missing consequential authorization for the following; do not request it again when the user has already granted the exact scope:

• production/staging deploy beyond agreed scope
• destructive operations (history rewrite, force push, data-destructive ops)
• actions with billing/security posture changes
• secret values not available in repo/runtime
• ambiguous DoD that materially changes outcome

Iteration/Stop Conditions

Stop and escalate with a concise blocker report when:

• The same verified external blocker leaves no meaningful authorized next step; two failed iterations alone are not a reason to stop when useful repair work remains
• external dependency blocks progress (provider outage, missing creds, account permission)
• conflicting review instructions cannot both be satisfied

Escalation report must include:

• what passed
• what failed
• evidence (commands/logs/API result)
• smallest decision needed from user

Output Contract

When claiming completion, always include:

• acceptance criteria checklist with pass/fail
• commands/tests run
• runtime evidence (endpoint/Lambda/log key lines)
• PR status (new actionable comments count)

Do not claim success without evidence.

Example

User request:

Take this bug from reproduction through root-cause proof, implementation, tests, review, and final validation.

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.