Agent skill · software engineering · sickn33
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.
Why this skill is useful
Adds a comprehensive end-to-end orchestration script that automates coding tasks from issue intake to acceptance verification, significantly enhancing workflow efficiency.
What it needs
Requires git installed locally. About 2k tokens when loaded. Last updated 2026-08-07. 44,571 stars on the source repository.
What this skill does
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 Deployment and PR monitoring are project-specific capabilities, not bundled sub-skills. Use the repository's actual deployment and review procedures; the legacy names deploy-dev, pr-watch, pr-review-autopilot, and git-ship are not available in AAS. 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, verify the explicitly authorized environment. A dev label does not grant deployment permission; inspect effects and use the project's deployment gate before changing any shared environment. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills sickn33/acceptance-orchestrator--635efc