/implement-batch

name: implement-batch
description: Multi-ticket batch workflow. Takes a batch of tickets, plans execution order, implements each via /implement in autonomous mode, runs cross-cutting quality passes, and presents results for final review.
model: opus

Implement-Batch - Multi-Ticket Orchestration Workflow

Orchestrates a batch of tickets as a cohesive unit. Creates a project branch, implements each ticket sequentially using the `/implement` workflow in autonomous mode, runs cross-cutting quality passes, and presents results for final human review.

Philosophy

**Maximize autonomy, minimize accumulated error.** The goal is to complete an entire batch of tickets without user intervention — but not at the cost of letting problems compound. When something goes wrong, pull the andon cord immediately rather than pressing forward and hoping later steps will compensate.

**The project branch is the integration point.** Each ticket gets its own topic branch. Work flows from topic branches into the project branch, never directly into main. This keeps main clean and gives the user a single decision point at the end: merge the project branch or don't.

**This skill is a for-loop, not an orchestrator.** Tickets are the work definition. Commander's intent does not apply here — the tickets carry the intent, and cross-cutting constraints (if any) inherit from the caller (`/implement-project` or `/lead-project`). The skill applies the autonomy discipline documented in [`references/autonomy.md`](../../references/autonomy.md) at the points where it does apply: the shared handoff template for andon-cord pulls, the cascade rule for `/implement` escalations.

**Cascade rule.** Escalations from `/implement` cascade up to this skill, not directly to the operator. When `/implement` would otherwise pull its own cord (e.g., 3-strike acceptance failure, unresolvable critical security finding), the batch skill catches that signal and pulls *its* cord with batch-level context (which ticket, which step, what's already merged). The caller has more context than the worker; the worker does not go around its caller.

Workflow Overview

┌──────────────────────────────────────────────────────┐
│                   BATCH WORKFLOW                     │
├──────────────────────────────────────────────────────┤
│  1. Receive ticket specification                     │
│  2. Detect issue tracker & fetch tickets             │
│  3. Batch planning (present to user)                 │
│  4. Create project branch                            │
│  5. Per-ticket loop:                                 │
│     ├─ 5a. Create topic branch                       │
│     ├─ 5b. Run /implement (autonomous mode)            │
│     ├─ 5c. Merge topic branch → project branch       │
│     ├─ 5d. Post-merge verification gate              │
│     └─ 5e. Delete topic branch                       │
│  6. Cross-cutting quality passes                     │
│     ├─ 6a. /refactor (SAFE aggression)               │
│     └─ 6b. /tidy-docs                               │
│  7. Final review (present to user)                   │
└──────────────────────────────────────────────────────┘

Andon Cord Protocol

**This protocol applies throughout the entire workflow.** When the andon cord is pulled:

1. **Stop all work immediately** — do not attempt to continue with other tickets or steps. 2. Produce a handoff using the **shared handoff template** in [`references/autonomy.md`](../../references/autonomy.md). The escalation must include pre-loaded options (2–3 named choices), an explicit recommendation, the one tradeoff that would flip the recommendation, and a pre-rebutted counterargument. Include the skill-specific state: which ticket and step failed, current branch state (what's merged into the project branch, what's in-progress on a topic branch), and tracker links if relevant. 3. Wait for user guidance before resuming.

**Andon cord triggers (skill-specific):**

• Acceptance verification fails 3 times (step 5b, `/implement` step 4)
• Unresolvable critical/high security findings (step 5b, `/implement` step 5a)
• Post-merge test suite failure (step 5d)
• Merge conflict (step 5c)
• Issue tracker unavailable or tickets can't be fetched (step 2)
• Empty ticket with no description (step 5b)
• Project branch already exists (step 4)
• Any unexpected failure not covered above

Workflow Details

1. Receive Ticket Specification

Accept tickets from the user in any of these forms:

• Explicit list of ticket IDs (e.g., `#12, #15, #18`)
• Tag/label query (e.g., "all tickets tagged `v2.0`")
• Milestone (e.g., "milestone: Sprint 4")
• User-provided description to search for

2. Detect Issue Tracker & Fetch Tickets

Detect the issue tracker and fetch ticket data per [`references/trackers.md`](../../references/trackers.md) (Detection Procedure + "Fetch (read)" operation). Fetch each ticket's title, description, acceptance criteria, labels, and dependencies.

**Andon cord** if tracker is unavailable or tickets can't be fetched.

3. Batch Planning

Analyze all fetched tickets and produce an execution plan:

**Dependency analysis:**

• Check for explicit "depends on" or "blocks" relationships between tickets
• Check for tickets referencing the same files or subsystems (implicit dependencies)
• Identify any tickets that must come before others

**Execution ordering:**

• Dependencies first (blocked tickets come after their blockers)
• Among independent tickets: simpler tickets first (builds momentum, establishes patterns)
• Flag any ambiguous tickets (missing description, no clear acceptance criteria)

**Present the plan to user:**

• Proposed execution order with rationale
• Any concerns about ambiguous or under-specified tickets
• Estimated scope (brief, qualitative — "3 small tickets, 1 medium")

**Wait for user approval** before proceeding. This is the one planned user interaction point.

4. Create Project Branch

• Identify the main branch (`mai