implement-batch

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. | | *