Drive one READY task end-to-end — implement in a worktree, independent adversarial review, bounded 3-iteration patch loop, then hand to a human for merge. Pass the issue number, e.g. "/deliver-task 42". A single-command composition of next-task + review-task + patch-task.
Installs into .claude/skills of the current project.
Are you the author of Deliver Task?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/blakemartz-deliver-task)
---
name: deliver-task
description: Drive one READY task end-to-end — implement in a worktree, independent adversarial review, bounded 3-iteration patch loop, then hand to a human for merge. Pass the issue number, e.g. "/deliver-task 42". A single-command composition of next-task + review-task + patch-task.
---
# deliver-task — one issue → a reviewed PR
You drive a single task through the whole loop yourself by dispatching the other roles as subagents (the Agent tool). One task, one branch, one PR, reviewed by a **fresh** agent, merged by a human. This is the single-task, Level-0 path (runbook §3); for continuous operation use `delivery-tick`.
Read `.claude/delivery.conf` for `NOTIFY_ESCALATE_CMD`. The sub-skills read the rest of the config themselves.
## Input
The issue number to deliver (e.g. `/delivery-loop:deliver-task 42`). It must be a READY task. No argument → report that you need an issue number and stop.
## Independence (the reason this is a composition, not one long session)
The reviewer must be a **fresh agent with no implementer context**. You spawn it as a separate Agent call whose prompt carries only the PR number — never your implementation reasoning. Never review the change yourself. That structural independence is the whole point (spec §3.4).
## Protocol
1. **Implement.** Spawn an agent: *"Run the /delivery-loop:next-task skill on issue #<n>. Report the PR number if you opened one, or why you stopped (claim lost, needs-human filed, queue conflict)."*
- If it did **not** open a PR (claim lost, blocked → needs-human, queue conflict), report that outcome and STOP — there is nothing to review.
2. **Review → patch loop, at most 3 iterations.** For round i = 1..3:
1. Spawn a **fresh** agent: *"Run the /delivery-loop:review-task skill on PR #<pr>. You have NO prior context on this change — that independence is required and deliberate. Execute every acceptance criterion in a clean checkout, then approve or request changes via gh. Report the URL of the review you actually posted; if you could not post it, say so explicitly."*
2. **Unposted verdict = escalate.** If the reviewer reached a verdict but could not post it to the PR, do not trust it (an unposted review did not happen — spec §11, runbook §7). Label the PR and issue `needs-human`, comment that the review could not be posted, run `NOTIFY_ESCALATE_CMD` if it is set, and STOP.
3. **Approved** → report **"PR #<pr> ready for human merge"** (with round number and the review URL) and STOP. You never merge.
4. **Unreviewable** (e.g. CI red) → treat like changes-requested; proceed to patch.
5. If this was round 3, break to step 3 (escalation).
6. **Patch.** Spawn an agent: *"Run the /delivery-loop:patch-task skill on PR #<pr>."* If it escalates (or dies), label `needs-human`, run `NOTIFY_ESCALATE_CMD` if set, report, and STOP. Otherwise continue to round i+1.
3. **Iterations exhausted.** No approval after 3 review/patch rounds: label the PR and issue `needs-human`, comment a concise summary of the remaining reviewer/patcher disagreement, run `NOTIFY_ESCALATE_CMD` if set, and STOP (spec §9).
## Exit condition
One of: **"ready for human merge"** (with PR + review URL); **"stopped"** (implementer never opened a PR); or **"needs-human"** (unposted verdict, patcher escalation, or 3 rounds without approval) — with the escalation persisted to GitHub, not just reported.
