How to use the Acceptance Orchestrator agent skill

What is an agent skill, and what does this one make the agent do?

An agent skill is a folder containing a SKILL.md file that gives an AI agent instructions for a specific kind of task. When a request matches the skill's description, the agent follows its workflow instead of improvising.

This skill runs a coding task as a state machine. The agent moves through states called intake, issue-gated, executing, review-loop, deploy-verify, accepted and escalated. It only reports success when every acceptance criterion has matching evidence. The core rule in the file is to optimise for a proven Definition of Done, not for 'code changed'.

• Reads the issue and extracts the task goal and Definition of Done (DoD).
• Stops immediately if the issue is not ready or the execution gate is not allowed.
• Hands implementation and local verification to the closed-loop-delivery sub-skill.
• Watches for relevant PR feedback using fixed polling windows of 3m, 6m and 10m.
• Verifies runtime behaviour in the authorised environment using real logs, API or Lambda results.
• Reports status with a pass/fail checklist, evidence, open risks and any input it needs from a human.

Install the acceptance-orchestrator skill

Download the ZIP file from this page. Unzip it and place the acceptance-orchestrator folder in one of two locations: ~/.claude/skills/ to make it available across your projects, or a project's .claude/skills/ folder to limit it to that repository.

Alternatively, in the Claude apps, open Settings, go to Capabilities, and upload the skill under Skills.

The skill's source file is SKILL.md. Check that it is present in the skill folder after unzipping.

• Option A: unzip into ~/.claude/skills/ for personal use across projects.
• Option B: unzip into a project's .claude/skills/ folder to share it with that repository.
• Option C: upload through Settings → Capabilities → Skills in the Claude apps.

Install the required sub-skills

This skill is an orchestrator. It depends on three sub-skills that must be installed from the same collection: create-issue-gate, closed-loop-delivery and verification-before-completion. Without them the workflow cannot run as written.

Deployment and pull request monitoring are not bundled. The file says the legacy names deploy-dev, pr-watch, pr-review-autopilot and git-ship are not available in the collection, so your project's own deployment and review procedures must be used.

• create-issue-gate
• closed-loop-delivery
• verification-before-completion

How do you trigger it with a natural request?

You do not need a special command. Describe a task that already has an issue or acceptance criteria and ask the agent to take it end to end. The skill's description is written so that requests about driving a task from intake through review, deployment and acceptance verification match it.

Include the issue number or the issue text, its status, the acceptance criteria and the target environment. The file defaults the target environment to dev, but a dev label does not by itself grant deployment permission.

Examples of requests and what to expect

Example request from the file: 'Take this issue and its acceptance criteria through implementation, validation, review, and a final evidence-backed verdict.' Paste the issue body with its DoD checklist along with it.

If the issue is still in draft, expect the agent to stop at the issue gate and not implement anything. If the criteria are missing, expect it to ask for them rather than guess.

• Issue #42 is ready with three acceptance criteria. Ask the agent to implement it, wait for review comments and verify the endpoint on dev.
• An issue is still marked draft. The agent reports it is blocked at the gate and asks for the issue to be made ready.
• A review comment conflicts with another reviewer's instruction. The agent escalates instead of picking one.

Safety, permissions and stop conditions

The skill runs no scripts and makes no network calls of its own, according to the file metadata. It does depend on credentials for any environment it must verify, and those are not specified in the file, so you must supply access yourself.

The agent is told to stop and escalate after two full retry rounds, when secrets or permissions are missing, when production action or destructive operations need approval, or when review instructions conflict. It always asks a human before prod or stage deploys beyond agreed scope, destructive git or data operations, billing or security changes, and when acceptance criteria are missing.

Because the skill only sets a process, configuration mistakes in the environments it touches can still cause harm. Keep a human approving each step for shared or production environments.

• Stop after 2 full iteration rounds if the DoD still fails.
• Escalate on missing secrets, permissions or external dependencies.
• Require human confirmation for prod/stage deploys, destructive operations, billing and security changes.
• Do not report done unless the status is accepted.

Tips for getting reliable results

Write acceptance criteria as checkable statements, because the agent must match each one to evidence. Vague criteria lead to escalation.

Read the status report. The Output Contract requires Status, Acceptance Criteria, Evidence, Open Risks and Need Human Input, so you can see exactly what was proven and what was not.

Do not use this for quick one-off edits. The workflow adds overhead and expects structured inputs.

• Use specific, testable acceptance criteria.
• Check the Evidence section before trusting an accepted status.
• Keep a human in the loop for any shared environment.