/delegate-backlog

name: delegate-backlog
description: Delegate an approved backlog to a real async coding agent (GitHub Copilot coding agent) so several stories are worked in parallel — one branch and PR per issue — then re-apply the kit's quality via pr-review/fix-pr on the resulting PRs. The async, throughput-first alternative to running work-story interactively per story. Verifies the async target exists (never fabricates a trigger) and never auto-merges. Use when a PO/dev wants to fan a backlog out to an async agent.

Delegate Backlog

Fan an **already-approved** backlog out to a **real async coding agent** so several stories are built in parallel — one branch, one PR per issue — and then re-apply the kit's quality on the PRs that come back. This is the **async, throughput-first alternative** to `work-story` (which works one story at a time, interactively, in your session).

> **Experimental (v1).** GitHub + Copilot coding agent only, and it leans on a young GitHub surface (§3–§4) — verify the mechanism is current and expect it to change.

**Be honest about the trade-off.** On the delegated path the kit's **in-session gates do not run** — the plan-approval gate, coverage/security/e2e, and stack conventions are *your* session's guarantees; an external agent runs its own loop. What the kit re-adds is at the **end**: `pr-review` / `fix-pr` on each resulting PR. So `delegate-backlog` **trades the kit's gates for throughput, and buys the quality back on review.** Say this to the user; never present a delegated PR as if the kit's gates produced it.

When to use vs. `work-story`

• **`work-story <KEY>`** — one story, **interactively**, with the full in-session gates. The default; highest assurance.
• **`delegate-backlog`** — many stories at once, **async**, gates re-applied on review. Use it for parallel throughput when the user explicitly wants to fan out a backlog and accepts the trade-off.

0. Preconditions (verify, don't assume)

1. **An approved backlog exists.** Delegate only stories the user has approved (typically the output of `plan-backlog`). If there's no approved backlog, run `plan-backlog` first — don't invent scope. 2. **The tracker is GitHub.** v1 targets **GitHub Copilot coding agent** only. If `tracker.type` isn't `github`, stop and say async delegation isn't available for this tracker yet (other targets are a later step). 3. **The async target is real and enabled** — see §3. Never fabricate a trigger (same doctrine as the "no fabricated automation" guard: the kit has no invented `/builder`-style mechanism).

1. Approval gate (mandatory — delegate nothing yet)

Show the user exactly **which issues** will be delegated, **to which agent**, and the **trade-off** (kit gates don't run async; re-applied via `pr-review`/`fix-pr`; nothing auto-merges). Wait for explicit approval. Only proceed on a yes. This is the same doctrine as `work-story`'s plan gate.

2. Enrich each issue with a self-contained brief

An async agent only has what's in the issue. Before delegating, make each issue carry everything it needs to build well — append (don't overwrite) a brief with:

• the **acceptance criteria** (from the story),
• the repo's **conventions** the agent should follow (point it at `CLAUDE.md` / `AGENTS.md` and `.github/copilot-instructions.md` if present — do **not** create those files here),
• the **build/test/lint commands** the repo uses (so its own CI can check the work),
• the **branch naming** convention (`<type>/<issue>-<slug>`),
• a **provenance line**: which plan/backlog this came from.

Push as much guidance into the issue as travels; don't rely on the async agent inheriting the kit's context (it won't). Don't mix in a *different* kit's instructions.

3. Verify the async target exists and is enabled (GitHub Copilot coding agent)

Copilot coding agent is triggered by **assigning the issue to Copilot**, but it must be **enabled for the repo/org** first (a GitHub Copilot feature). **Verify, don't assume** — and because this surface is young, confirm the mechanism against current GitHub docs rather than trusting a hardcoded command:

• **Availability check:** query the repo's assignable actors for the Copilot bot — GraphQL `repository.suggestedActors(capabilities: [CAN_BE_ASSIGNED], first: 100)`, looking for the Copilot coding-agent bot (login like `copilot-swe-agent` / `Copilot`). If it isn't there, **Copilot coding agent isn't enabled** — stop and tell the user how to enable it (repo/org Copilot settings). Don't fake a trigger.

4. Delegate each issue

For each approved issue (independent ones in parallel; for a dependency chain, delegate in dependency order, or hold a dependent until the user **merges** its prerequisite PR — since the kit never auto-merges, a held dependent waits on that human merge, so tell the user it's waiting rather than letting it stall silently):

• **Assign the issue to Copilot.** The current supported path is the GraphQL `replaceActorsForAssignable` mutation with the Copilot bot's actor id (or `gh` if your version supports assigning Copilot) — **verify it's current** before relying on it. On assignment, Copilot starts a session and opens a **draft PR**.
• **Confirm by read-back** (`gh issue view <n> --json assignees`) — never report an issue as delegated on the exit code alone.
• **Capture the resulting PR from the issue's timeline / linked PRs** — never invent a PR number (same guard as `create-pr`/`fix-pr`: only report a PR the API actually returned).

5. Track issue → branch → PR in a run manifest

Keep one **run manifest** so the fan-out is legible and resumable — a table posted as a comment on the parent/epic issue (or a `docs/` file if the user prefers):

| issue | assigned | branch | PR | PR state | reviewed | |---|---|---|---|---|---|

Update it as PRs appear and as review runs. The manifest is the single place the user watches progress — don't scatter status across many comments.

6. Review loop — re-apply the kit's quality

Th