Acceptance orchestrator
Skill ranbot-ai/awesome-skills/skills/acceptance-orchestrator
Awesome Claude Skills, Tools for Customizing Claude AI workflows
npx -y skills add ranbot-ai/awesome-skills --skill acceptance-orchestratorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.7 KB, 754 tokens by cl100k_base, as published. Nobody here has run it
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-gateclosed-loop-deliveryverification-before-completion
Optional supporting skills:
deploy-devpr-watchpr-review-autopilotgit-ship
Inputs
Require these inputs:
- issue id or issue body
- issue status
- acceptance criteria (DoD)
- target environment (
devdefault)
Fixed defaults:
- max iteration rounds =
2 - PR review polling =
3m -> 6m -> 10m
State Machine
intakeissue-gatedexecutingreview-loopdeploy-verifyacceptedescalated
Workflow
-
Intake
- Read issue and extract task goal + DoD.
-
Issue gate
- Use
create-issue-gatelogic. - If issue is not
readyor execution gate is notallowed, stop immediately. - Do not implement anything while issue remains
draft.
- Use
-
Execute
- Hand off to
closed-loop-deliveryfor implementation and local verification.
- Hand off to
-
Review loop
- If PR feedback is relevant, batch polling windows as:
- wait
3m - then
6m - then
10m
- wait
- After the
10mround, stop waiting and process all visible comments together.
- If PR feedback is relevant, batch polling windows as:
-
Deploy and runtime verification
- If DoD depends on runtime behavior, deploy only to
devby default. - Verify with real logs/API/Lambda behavior, not assumptions.
- If DoD depends on runtime behavior, deploy only to
-
Completion gate
- Before any claim of completion, require
verification-before-completion. - No success claim without fresh evidence.
- Before any claim of completion, require
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
2full 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 / escalatedAcceptance Criteria: pass/fail checklistEvidence: commands, logs, API results, or runtime proofOpen Risks: anything still uncertainNeed 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.
Gives 0 of the 12 instructions most agent orchestration skills give in 754 tokens
Counted across 742 of the 995 authors here whose files we hold, read 2026-08-06
- run the full test suite after integrating changesin 53 of 742, across 20 files
- reference existing artifacts by path or URLin 52 of 742, across 22 files
- dispatch one agent per independent problem domainin 50 of 742, across 17 files
- verify fixes do not conflictin 45 of 742, across 13 files
- include a suggested skills section in the documentin 45 of 742, across 15 files
- redact sensitive informationin 41 of 742, across 11 files
- save to the temporary directory of the operating systemin 39 of 742, across 9 files
- tailor the document to user-provided focus argumentsin 39 of 742, across 9 files
- spot check agent changes for systematic errorsin 34 of 742, across 7 files
- write a handoff document summarising the current conversationin 31 of 742, across 6 files
- assign each agent a specific scopein 23 of 742, across 8 files
- provide specific scope and clear goalin 23 of 742, across 5 files
Said here and by no other author read
- read the issue and extract goals
- require fresh evidence before completion
- include pass/fail checklist in status reports
- stop if success criteria are missing
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.