acceptance-orchestrator
starsforks
How to install acceptance-orchestrator?
sickn33/agentic-awesome-skills/acceptance-orchestrator
$npx -y skills add sickn33/agentic-awesome-skills --skill acceptance-orchestratorUse 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
| 1 | # Acceptance Orchestrator |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Orchestrate coding work as a state machine that ends only when acceptance criteria are verified with evidence or the task is explicitly escalated. |
| 6 | |
| 7 | Core rule: **do not optimize for "code changed"; optimize for "DoD proven".** |
| 8 | |
| 9 | ## When to Use |
| 10 | - The task already has an issue or clear acceptance criteria and should run end-to-end with minimal human re-intervention. |
| 11 | - You need structured handoff across implementation, review, deployment, and final verification. |
| 12 | - You want explicit stop conditions and escalation instead of silent partial completion. |
| 13 | |
| 14 | ## Required Sub-Skills |
| 15 | |
| 16 | - `create-issue-gate` |
| 17 | - `closed-loop-delivery` |
| 18 | - `verification-before-completion` |
| 19 | |
| 20 | Optional supporting skills: |
| 21 | - `deploy-dev` |
| 22 | - `pr-watch` |
| 23 | - `pr-review-autopilot` |
| 24 | - `git-ship` |
| 25 | |
| 26 | ## Inputs |
| 27 | |
| 28 | Require these inputs: |
| 29 | - issue id or issue body |
| 30 | - issue status |
| 31 | - acceptance criteria (DoD) |
| 32 | - target environment (`dev` default) |
| 33 | |
| 34 | Fixed defaults: |
| 35 | - max iteration rounds = `2` |
| 36 | - PR review polling = `3m -> 6m -> 10m` |
| 37 | |
| 38 | ## State Machine |
| 39 | |
| 40 | - `intake` |
| 41 | - `issue-gated` |
| 42 | - `executing` |
| 43 | - `review-loop` |
| 44 | - `deploy-verify` |
| 45 | - `accepted` |
| 46 | - `escalated` |
| 47 | |
| 48 | ## Workflow |
| 49 | |
| 50 | 1. **Intake** |
| 51 | - Read issue and extract task goal + DoD. |
| 52 | |
| 53 | 2. **Issue gate** |
| 54 | - Use `create-issue-gate` logic. |
| 55 | - If issue is not `ready` or execution gate is not `allowed`, stop immediately. |
| 56 | - Do not implement anything while issue remains `draft`. |
| 57 | |
| 58 | 3. **Execute** |
| 59 | - Hand off to `closed-loop-delivery` for implementation and local verification. |
| 60 | |
| 61 | 4. **Review loop** |
| 62 | - If PR feedback is relevant, batch polling windows as: |
| 63 | - wait `3m` |
| 64 | - then `6m` |
| 65 | - then `10m` |
| 66 | - After the `10m` round, stop waiting and process all visible comments together. |
| 67 | |
| 68 | 5. **Deploy and runtime verification** |
| 69 | - If DoD depends on runtime behavior, deploy only to `dev` by default. |
| 70 | - Verify with real logs/API/Lambda behavior, not assumptions. |
| 71 | |
| 72 | 6. **Completion gate** |
| 73 | - Before any claim of completion, require `verification-before-completion`. |
| 74 | - No success claim without fresh evidence. |
| 75 | |
| 76 | ## Stop Conditions |
| 77 | |
| 78 | Move to `accepted` only when every acceptance criterion has matching evidence. |
| 79 | |
| 80 | Move to `escalated` when any of these happen: |
| 81 | - DoD still fails after `2` full rounds |
| 82 | - missing secrets/permissions/external dependency blocks progress |
| 83 | - task needs production action or destructive operation approval |
| 84 | - review instructions conflict and cannot both be satisfied |
| 85 | |
| 86 | ## Human Gates |
| 87 | |
| 88 | Always stop for human confirmation on: |
| 89 | - prod/stage deploys beyond agreed scope |
| 90 | - destructive git/data operations |
| 91 | - billing or security posture changes |
| 92 | - missing user-provided acceptance criteria |
| 93 | |
| 94 | ## Output Contract |
| 95 | |
| 96 | When reporting status, always include: |
| 97 | - `Status`: intake / executing / accepted / escalated |
| 98 | - `Acceptance Criteria`: pass/fail checklist |
| 99 | - `Evidence`: commands, logs, API results, or runtime proof |
| 100 | - `Open Risks`: anything still uncertain |
| 101 | - `Need Human Input`: smallest next decision, if blocked |
| 102 | |
| 103 | Do not report "done" unless status is `accepted`. |
| 104 | |
| 105 | ## Limitations |
| 106 | - Use this skill only when the task clearly matches the scope described above. |
| 107 | - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. |
| 108 | - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing. |
People who liked this also viewed
6 picksType
- paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026
- subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026
- dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026
- browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 2026
- wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 2026
- wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 2026
