implement-batch

What this skill does

# 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 (`main` or `master`)
- Create project branch from current HEAD: `feat/batch-<descriptive-name>`
- Branch name derived from the tag, milestone, or a brief summary of the ticket batch
- **Andon cord** if branch already exists — ask user whether to resume or start fresh

### 5. Per-Ticket Execution Loop

For each ticket in the planned order:

#### 5a. Create Topic Branch

- Checkout project branch (ensure it's current)
- Create topic branch: `feat/issue-<number>-<brief-slug>`
- The slug is derived from the ticket title (lowercase, hyphens, truncated to ~40 chars)

#### 5b. Run `/implement` Workflow (Autonomous Mode)

Follow the `/implement` workflow with these overrides for autonomous operation:

| `/implement` Step                             | Autonomous Override                                                                                                                                                                                              |
|---------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Step 1** (requirements)                   | Pre-loaded from ticket body. Do not prompt user for requirements. If the ticket lacks explicit acceptance criteria, derive them from the description. If the description is empty or incoherent, **andon cord**. |
| **Step 2** (planning)                       | Follow normal conditional logic — invoke `swe-planner` for complex tasks, skip for simple ones.                                                                                                                  |
| **Steps 3-4** (implementation + acceptance) | Follow normal logic. If acceptance verification fails 3 times, **andon cord** (do not escalate to user within `/implement` — escalate here at the batch level).                                                    |
| **Step 5a** (security review)               | Follow normal logic. If critical/high findings cannot be resolved by the implementation agent, **andon cord**.                                                                                                   |
|