acceptance-orchestrator

# Acceptance Orchestrator ## Overview Orchestrate coding work as a state machine that ends only when acceptance criteria are verified with evidence or the task is explicitly escalated. Core rule: **do not optimize for "code changed"; optimize for "DoD proven".** ## When to Use - The task already has an issue or clear acceptance criteria and should run end-to-end with minimal human re-intervention. - You need structured handoff across implementation, review, deployment, and final verification. - You want explicit stop conditions and escalation instead of silent partial completion. ## Required Sub-Skills - `create-issue-gate` - `closed-loop-delivery` - `verification-before-completion` Optional supporting skills: - `deploy-dev` - `pr-watch` - `pr-review-autopilot` - `git-ship` ## Inputs Require these inputs: - issue id or issue body - issue status - acceptance criteria (DoD) - target environment (`dev` default) Fixed defaults: - max iteration rounds = `2` - PR review polling = `3m -> 6m -> 10m` ## State Machine - `intake` - `issue-gated` - `executing` - `review-loop` - `deploy-verify` - `accepted` - `escalated` ## Workflow 1. **Intake** - Read issue and extract task goal + DoD. 2. **Issue gate** - Use `create-issue-gate` logic. - If issue is not `ready` or execution gate is not `allowed`, stop immediately. - Do not implement anything while issue remains `draft`. 3. **Execute** - Hand off to `closed-loop-delivery` for implementation and local verification. 4. **Review loop** - If PR feedback is relevant, batch polling windows as: - wait `3m` - then `6m` - then `10m` - After the `10m` round, stop waiting and process all visible comments together. 5. **Deploy and runtime verification** - If DoD depends on runtime behavior, deploy only to `dev` by default. - Verify with real logs/API/Lambda behavior, not assumptions. 6. **Completion gate** - Before any claim of completion, require `verification-before-completion`. - No success claim without fresh evidence. ## Stop Conditions Move to `accepted` only when every acceptance criterion has matching evidence. Move to `escalated` when any of these happen: - DoD still fails after `2` full rounds - missing secrets/permissions/external dependency blocks progress - task needs production action or destructive operation approval - review instructions conflict and cannot both be satisfied ## Human Gates Always stop for human confirmation on: - prod/stage deploys beyond agreed scope - destructive git/data operations - billing or security posture changes - missing user-provided acceptance criteria ## Output Contract When reporting status, always include: - `Status`: intake / executing / accepted / escalated - `Acceptance Criteria`: pass/fail checklist - `Evidence`: commands, logs, API results, or runtime proof - `Open Risks`: anything still uncertain - `Need Human Input`: smallest next decision, if blocked Do not report "done" unless status is `accepted`. ## Diff History - **v00.33.0**: Ingested from antigravity-awesome-skills community repo --- ## Why This Skill Exists Implement — <!-- SR_40: auto-generated from frontmatter `purpose`/`description` (OPP-Phase3). Expand with domain-specific rationale. --> ## What If Fails - condition: Código não disponível para análise <!-- SR_40: auto-generated from frontmatter `what_if_fails` (OPP-Phase3). -->