'v1'

2026-07-06 18:06:28 +02:00
parent 9d189020de
commit fdbe811cdc
279 changed files with 60644 additions and 0 deletions
@@ -0,0 +1,116 @@
+---
+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.