Antigravity-awesome-skills acceptance-orchestrator

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.

install

source · Clone the upstream repo

git clone https://github.com/sickn33/antigravity-awesome-skills

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/sickn33/antigravity-awesome-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/plugins/antigravity-awesome-skills-claude/skills/acceptance-orchestrator" ~/.claude/skills/sickn33-antigravity-awesome-skills-acceptance-orchestrator && rm -rf "$T"

manifest: plugins/antigravity-awesome-skills-claude/skills/acceptance-orchestrator/SKILL.md

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

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

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.