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 (`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**.                                                                                                   |
| **Steps 5b-5c** (refactoring/perf review)   | Follow normal logic — these are advisory.                                                                                                                                                                        |
| **Step 6** (implement review feedback)      | Follow normal logic.                                                                                                                                                                                             |
| **Step 7** (peer review)                    | Follow normal logic. Handle deep issues autonomously — trust agents. If peer review breaks tests, revert peer review changes per standard `/implement` logic.                                                      |
| **Step 8** (coverage/quality verification)  | Follow normal logic. Handle autonomously — if tests pass, proceed. Do not prompt user for approval of minor issues.                                                                                              |
| **Step 9** (documentation)                  | Follow normal logic.                                                                                                                                                                                             |
| **Step 10** (final verification)            | Follow normal logic.                                                                                                                                                                                             |
| **Step 11a** (commit)                       | Auto-commit with ticket reference. Use `Fixes #<number>` in the commit message.                                                                                                                                  |
| **Step 11b** (ticket update/close)          | Post a comment on the ticket summarizing changes made. **Do not close** the ticket — leave that for the user after final review.                                                                                 |
| **Step 11c** (rebase on main)               | **Skip entirely.** We're on topic branches off the project branch, not main.                                                                                                                                     |

#### 5c. Merge Topic Branch into Project Branch

- Checkout project branch
- Merge: `git merge --no-ff feat/issue-<number>-<brief-slug>`
- The `--no-ff` preserves topic branch history for clarity
- **Andon cord** on merge conflict — do not attempt auto-resolution

#### 5d. Post-Merge Verification Gate

- Run the full test suite on the project branch
- Run linters/formatters
- **Andon cord** if tests fail — the merge introduced a regression

#### 5e. Clean Up Topic Branch

- Delete the merged topic branch: `git branch -d feat/issue-<number>-<brief-slug>`
- Update orchestrator state: mark ticket as done

### 6. Cross-Cutting Quality Passes

After all tickets are implemented and merged into the project branch:

#### 6a. Refactoring

Run the `/refactor` workflow with these parameters:
- **Aggression ceiling:** SAFE (conservative — only SAFEST and SAFE changes)
- **Custom QA instructions:** None (standard test suite verification)
- **Scope:** Entire codebase
- The `/refactor` workflow handles its own iteration loop, commits, and QA verification

#### 6b. Documentation Review

Run the `/tidy-docs` workflow:
- Full documentation audit (not git-diff scoped)
- Fixes committed separately

### 7. Final Review

Present comprehensive summary to user:

```
## Batch Complete

### Tickets Implemented
- #12: <title> — <brief outcome>
- #15: <title> — <brief outcome>
- #18: <title> — <brief outcome>

### Statistics
- Total commits: N
- Net lines changed: +/-N
- Tests added/modified: N
- Documentation files updated: N

### Quality Passes
- Refactoring: N improvements, net -N lines
- Documentation: N updates

### Branch Status
- Project branch: feat/batch-<name>
- Base branch: <main branch>
- Ready to merge
```

User decides next steps: merge to main, further work, or discard.

## State Management

The orchestrator maintains:
- **Ticket list**: all tickets with status (pending / in-progress / done / failed)
- **Current ticket**: which ticket is being worked on
- **Execution order**: from the planning step
- **Summary log**: brief notes on each completed ticket (avoid context bloat — just ticket number, title, outcome, and commit count)
- **Branch names**: project branch and any active topic branches (for cleanup if needed)

## Agent Coordination

**Sequential execution:**
- One ticket at a time, one agent at a time
- Each agent completes before the next begins
- No parallel agent execution

**Context management:**
- The `/implement` workflow within each ticket manages its own agent lifecycle
- The batch orchestrator tracks only summary-level state across tickets
- Keep per-ticket summaries brief to avoid context window bloat across a large batch

**Fresh state per ticket:**
- Each ticket starts with a fresh topic branch
- The `/implement` workflow starts from scratch for each ticket
- No state leaks between tickets except the cumulative project branch

## Integration with Other Skills

**Relationship to `/implement`:**
- `/implement-batch` is a higher-level orchestrator that runs `/implement` for each ticket
- `/implement` handles the full development cycle for a single ticket
- `/implement-batch` adds: batching, ordering, branching strategy, cross-cutting quality passes

**Relationship to `/scope`:**
- `/scope` creates tickets; `/implement-batch` consumes them
- Typical flow: `/scope` to plan and create tickets, then `/implement-batch` to implement the batch

**Relationship to `/refactor`, `/tidy-docs`:**
- These run as cross-cutting quality passes after all tickets are implemented
- They catch issues that span multiple tickets or emerge from their interaction