acceptance-orchestrator skill
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.
Is the acceptance-orchestrator skill safe?
Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.
No findings.
Install the acceptance-orchestrator skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/sickn33/agentic-awesome-skills.git /tmp/agentic-awesome-skills mkdir -p ~/.claude/skills cp -r /tmp/agentic-awesome-skills/plugins/agentic-awesome-skills-claude/skills/acceptance-orchestrator ~/.claude/skills/acceptance-orchestrator
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
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.
Example
User request:
Take this issue and its acceptance criteria through implementation, validation, review, and a final evidence-backed verdict.
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.
More skills from sickn33/agentic-awesome-skills
- A00-andruia-consultantArquitecto de Soluciones Principal y Consultor Tecnológico de Andru.ia. Diagnostica y traza la hoja de ruta óptima para proyectos de IA en español.
- F007Security audit, hardening, threat modeling (STRIDE/PASTA), Red/Blue Team, OWASP checks, code review, incident response, and infrastructure security for any project.
- A10-andruia-skill-smithIngeniero de Sistemas de Andru.ia. Diseña, redacta y despliega nuevas habilidades (skills) dentro del repositorio siguiendo el Estándar de Diamante.
- A20-andruia-niche-intelligenceEstratega de Inteligencia de Dominio de Andru.ia. Analiza el nicho específico de un proyecto para inyectar conocimientos, regulaciones y estándares únicos del sector. Actívalo tras definir el nicho.
- A2slides-ppt-generatorAI-powered presentation generation via the 2slides API — create slides from text, match a reference image style, summarize documents into decks, add AI voice narration, and export pages/audio. Use for any \"make slides\", \"create a deck\", or \"slides from this document\" request.
- A3d-web-experienceExpert in building 3D experiences for the web - Three.js, React
- Aab-test-setupUse when designing an A/B or split test: define the hypothesis, control and variants, estimate sample size, verify tracking, and predeclare metrics and stopping rules.
- Aab-testingWhen the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program.
- Aaccess-reviewConduct periodic access reviews and certifications. Implement access
- Aaccessibility-compliance-accessibility-auditYou are an accessibility expert specializing in WCAG compliance, inclusive design, and assistive technology compatibility. Conduct audits, identify barriers, and provide remediation guidance.
- Aaccesslint-auditFind and fix WCAG 2.2 accessibility issues. Two modes — report (sweep a codebase or page, produce a prioritized written report, no edits) and fix (audit→edit→verify loop on a target). Prefers direct-CDP live-DOM auditing; falls back to a browser-MCP composition or HTML-string audits.
- Aaccesslint-diffDiff a live page's accessibility violations against a baseline — by default compares uncommitted changes (stash-based), or pass --branch [<name>] to diff against a branch. Reports only new violations introduced, violations fixed, and pre-existing count. Use `scan` for a full audit with no diffing.