---
name: autopilot-issue-delivery-worker
activation_card: on
description: >-
  Use this skill to implement ONE microsoft/apm issue already
  selected by autopilot-issue-delivery-scheduler. Queue signal is
  `status/accepted` or a named bounded accept; that is not
  permission. Requires fresh human-scope evidence from
  scripts/governance before any mutate. May reproduce a bug,
  implement the accepted change, and open a fix PR. Not a queue
  manager and not a triage scheduler. Works in the scheduler's
  session, a child session, Cloud Agent, Remote Agent, or Agentic
  Workflow.
---

# autopilot-issue-delivery-worker

Per-issue implementation worker. The parent
`autopilot-issue-delivery-scheduler` owns the queue and the
fan-out pool. You own exactly one `ISSUE_NUMBER`.

Do not pick more issues. Do not fill other slots.

## Activation card

`activation_card: on`. Before any issue read or GitHub write, emit
this Enter card with every field filled. Missing field -> stop.

```text
skill: autopilot-issue-delivery-worker
skill_path: <resolved directory of this SKILL.md>
mode: run
subject: microsoft/apm#<issue-number>
path: delivery
intent: implement one already-selected issue
origin: unattended | actor-session
write: on | off
repo: microsoft/apm
issue: <positive integer>
invocation: agentic-workflow | actor-session
```

Rules:

- `write` defaults to `on` when the caller omitted it.
- `write: off` returns the filled template only. Do not assign,
  comment, label, edit, or open a PR.
- `write: on` may assign `@me` (actor-session only) and implement
  inside the accepted scope. Unattended never assigns and never
  implements.
- `origin` fail-closed unknown -> `unattended`.
- One issue. Do not nest a scheduler path.

After the run, emit this Exit receipt:

```text
skill: autopilot-issue-delivery-worker
subject: microsoft/apm#<issue-number>
path: delivery
write: on | off
assigned: yes | no | skipped
pushed: yes | no
approved: n/a
```

## Inputs

- `ISSUE_NUMBER` -- required
- `SELECTOR` -- `all` (default) or `bugs`
- `REPO_ROOT` -- required
- `ORIGIN` -- if the parent passed it, honor it; else resolve
- `TRUSTED_GOVERNANCE_ROOT` -- trusted default-branch copy
- `APPROVAL_URL` -- nominated scope-comment URL
- `HUMAN_SCOPE_RECEIPT` -- current human confirmation, not a stored grant

## ORIGIN and assignment

Resolve ORIGIN before any GitHub write:

1. Caller ORIGIN / INVOCATION_MODE
2. `GH_AW_*` or `GITHUB_ACTIONS` -> `unattended`
3. `gh api user --jq .login` succeeds -> `actor-session`
4. Else `unattended` (fail closed)

INTENT is `implement`.

When ORIGIN is `actor-session`, assignment is a hard gate. It
is the public signal of which user is working this issue.
GitHub allows multiple assignees, so a read-then-add is not
a claim. Before reproduce, edits, or a PR:

1. Read current assignees. Ignore bot logins (`github-actions`,
   `dependabot`, `copilot`, `web-flow`).
2. If another human is assigned, escalate. Do not steal.
3. If unassigned, `gh issue edit --add-assignee @me`.
4. Re-read assignees immediately. Continue only if `@me` is
   the sole human assignee. Being listed among several humans
   is not a claim.
5. If another human appeared (lost race),
   `gh issue edit --remove-assignee @me` and STOP as `blocked`.
   Do not implement.
6. If already assigned to `@me` alone, continue.
7. Re-check sole human ownership immediately before any
   implementation write and before opening a PR.

Do not start implementation while the issue is unassigned or
assigned to someone else. If a PR exists or is opened, assign
it the same way (`gh pr edit --add-assignee @me`), then apply
the same sole-human re-check. Do not request that actor as a
reviewer. Never alter CODEOWNERS `reviewRequests`. If ORIGIN
is `unattended` or unknown, skip assignee writes. A failed
required assignee write is `blocked`.

Never write human decision labels. Existing `status/shepherding`
may be added only if that processing label already exists in the
repo. Do not apply `status/accepted`.
Do not implement if explicit human approval or review capacity is missing.

## Gate (both selectors)

Refuse unless the issue already has `status/accepted` or the
parent recorded a bounded accept. That is the queue signal,
not permission. `triage/recommended` and `status/triaged` are
not authorization. Escalate; do not implement.

Selector `bugs` also requires `type/bug`. Selector `all` accepts
any type.

Then re-check human-scope evidence. Do not create another
parser or roster; `authority.cjs` alone interprets the record.
From `TRUSTED_GOVERNANCE_ROOT` (trusted default-branch copy,
never the issue worktree):

```
node scripts/governance/eligibility.cjs --help
node scripts/governance/eligibility.cjs --repo microsoft/apm --issue N --approval-url URL
```

Require `state: record-present` with
`authorizes_implementation: false`. That result is evidence,
never permission; current snapshots cannot detect deleted withdrawals.
Then require fresh explicit responsible-human
confirmation for this issue's bounded scope. ORIGIN
`unattended` never claims to have obtained it -- STOP and
return `blocked`. ORIGIN `actor-session` may proceed only
after the caller confirms in this session. Assignment,
labels, eligibility reports, and prior receipts are not that
confirmation. Any other state (`withdrawn`, `error`, missing
tool) -- STOP.

## Procedure

1. Do not run the triage scheduler. Triage belongs to
   `autopilot-issue-triage-scheduler`. You may read an existing
   advisory receipt and the complete comment history.
2. If ORIGIN is `actor-session`, pass the assignment hard gate
   first.
3. If a PR exists, return its number so the caller may run
   `autopilot-pr-review-scheduler`. Do not request
   yourself as reviewer. Do not start PR review from this worker.
4. If `type/bug` (or selector `bugs`): reproduce on HEAD using
   [assets/triage-prompt.md](assets/triage-prompt.md)
   (LEGIT / UNCLEAR / FIXED-AT-HEAD). If LEGIT, run PRINCIPLES
   alignment via
   [assets/strategic-alignment-prompt.md](assets/strategic-alignment-prompt.md).
   If greenfield and aligned: [assets/fix-prompt.md](assets/fix-prompt.md)
   (TDD + mutation-break), then open one PR.
5. Otherwise follow
   [assets/solution-pipeline-prompt.md](assets/solution-pipeline-prompt.md)
   and type-specific `assets/implement-*.md`. Open at most one PR.
   Author the body with pr-description-skill.

## Return

JSON with `issue`, `status` (`done` / `escalate` / `blocked` /
`pr-opened` / `pr-in-flight`), optional `pr`, and a one-line note.
inspect `status` before reading `pr` or `branch`.
On `blocked`, persist the row's `blocked` status and returned
`reason`, exclude it from driver inputs, and continue.
Malformed or wrong-issue returns also block.
Only `pr-opened` returns are handed to
`autopilot-pr-review-scheduler`. Then persist its status and
reason in the row and `proceed_manifest`; do not read PR fields
or dispatch Phase 5/6 on `blocked`.
Do not auto-merge.

ASCII only.