acceptance-orchestrator

Original：🇺🇸 English

Translated

Use when a coding task should be driven end-to-end from issue intake through implementation, review, deployment, and acceptance verification with minimal human re-intervention.

3installs

Sourcesickn33/antigravity-awesome-skills

Added on2026-03-30

NPX Install

npx skill4agent add sickn33/antigravity-awesome-skills acceptance-orchestrator

SKILL.md Content

View Translation Comparison →

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

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

Intake
- Read issue and extract task goal + DoD.
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
```
  .
Execute
- Hand off to
```
closed-loop-delivery
```
  for implementation and local verification.
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.
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.
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

.