117 lines
3.5 KiB
Markdown
117 lines
3.5 KiB
Markdown
---
|
|
name: acceptance-orchestrator
|
|
description: 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.
|
|
risk: safe
|
|
source: community
|
|
date_added: "2026-03-12"
|
|
---
|
|
|
|
# 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`.
|
|
|
|
## 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.
|