acceptance-orchestrator
پیشبرد سرتاسری کار کدنویسی تا تأیید پذیرش
این اسکیل کار کدنویسی را از دریافت issue تا پیادهسازی، بازبینی، استقرار و تأیید پذیرش با کمترین مداخلهٔ انسانی پیش میبرد؛ با ماشین حالت و شرط توقف.
چه چیزی میگیرید
- ماشین حالت
- گردش کار
- شرط توقف
برای چه کاری خوب است
- کارهای کامل خودکار
- تیمهای کوچک
برای چه کاری نیست
- کارهای پرریسک بدون نظارت
دربارهٔ این اسکیل
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
Deployment and PR monitoring are project-specific capabilities, not bundled sub-skills.
Use the repository's actual deployment and review procedures; the legacy namesdeploy-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 (
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 notreadyor execution gate is notallowed, stop immediately. - Do not implement anything while issue remainsdraft.
- Execute - Hand off to
closed-loop-deliveryfor implementation and local verification.
- Review loop - If PR feedback is relevant, batch polling windows as: - wait
3m- then6m- then10m- After the10mround, stop waiting and process all visible comments together.
- Deploy and runtime verification - If DoD depends on runtime behavior, verify the explicitly authorized environment. - A
devlabel does not grant deployment permission; inspect effects and use the project's deployment gate before changing any shared environment. - 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
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.
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.