Batch Linear Ticket Resolver

Orchestrate parallel investigation, planning, and implementation of multiple Linear tickets. This skill is a thin orchestrator — it coordinates specialized agents and handles user-facing gates in the main conversation context.

Architecture

Phase 1: Fan-Out Investigation        → linear-ticket-investigator agents
Phase 2: Correlation (main context)   → cross-ticket analysis
Phase 3: Approval Gate (main context) → user picks tickets to proceed
Phase 4: Fan-Out Planning             → aw-planner agents (in worktrees)
Phase 5: Plan Review Gate (optional)  → user inspects plans before execution
Phase 6: Fan-Out Execution            → aw-executor agents
Phase 7: Results (main context)       → status table + Linear updates

The autonomous-workflow is split into two agents — aw-planner and aw-executor (the aw- prefix is short for "autonomous-workflow" and groups the pair together) — connected by plan.md:

aw-planner runs Phases 0–2 (validate, plan, create worktree, gate on confidence(plan) ≥ 90%).
aw-executor runs Phases 3–7 (implement, test, document, draft PR, watch CI).

The planner already runs confidence(plan) internally. Phase 5 of this skill is an optional, additional human review for batch contexts where the user wants to compare plans across tickets before dispatching executors in parallel.

Prerequisites

Dependency	Purpose	Required?
Linear MCP (`mcp__claude_ai_Linear__*`)	Read tickets, post PR comments	Yes
`linear-ticket-investigator` agent	Phase 1 fan-out	Yes
`aw-planner` + `aw-executor` agents (from `autonomous-workflow`, under the `aw-` namespace)	Phases 4 & 6	Yes
`gh` CLI	PR creation by the executor	Yes
`gw` CLI	Worktree management (planner)	Recommended
Project domain-navigator skill	Step 2 of investigation in monorepos	Optional — see Customization

Rules

Rule	Description
cross-ticket-correlation	Detect shared root causes, duplicates, conflicts
batch-approval-ux	Summary table, approval commands, status values

Investigation rules live in linear-ticket-investigator. Planning and execution rules live in aw-planner and aw-executor. This skill only owns batch-level orchestration and the two user-facing gates.

Arguments

Parse $ARGUMENTS for ticket identifiers.

If $ARGUMENTS contains ticket IDs (e.g., SUP-123 ENG-456), use them directly.
If $ARGUMENTS contains a Linear filter/project URL, extract relevant ticket IDs.
If $ARGUMENTS is empty, ask the user to provide ticket IDs.

Accept formats: SUP-123, ENG-456, 123 (bare number), Linear URLs. Comma-, space-, or newline-separated.

Phase 1: Parallel Investigation (Fan-Out)

Spawn one linear-ticket-investigator agent per ticket using the Agent tool with subagent_type: "linear-ticket-investigator". Launch ALL agents in a single message.

Each agent's prompt is minimal — the agent definition contains the full investigation methodology:

Investigate Linear ticket {TICKET_ID}.

{Optional context from the user, e.g., "this is in the alerting component"}

Wait for all agents to return before proceeding. If some fail, proceed with what you have and offer to re-run the failed ones.

Phase 2: Cross-Ticket Correlation

Analyze findings in the main context (no agent needed). See cross-ticket-correlation for the methodology.

Detect: shared root causes, file conflicts, duplicates, dependencies. Group correlated tickets so a single PR can resolve multiple.

Phase 3: Approval Gate

Present findings using the format in batch-approval-ux: summary table, per-ticket details, correlation notes, information gaps, and an approval prompt.

Tickets with status Needs Info cannot be approved until gaps are resolved. If the user provides missing info, re-run linear-ticket-investigator for those tickets only and re-present.

Approval commands: all, 1, 3, 5, all including risky, review plans, none.

Phase 4: Parallel Planning (Fan-Out)

For each approved ticket (or correlated group), launch an aw-planner agent using the Agent tool with subagent_type: "aw-planner" and isolation: "worktree". Launch ALL approved planners in a single message.

Each planner receives the full Decision Pack from the investigator — it does not re-investigate, but it will validate, refine, and produce a self-contained plan.md gated by confidence(plan).

Plan a fix for Linear ticket {TICKET_ID}: {Title}

## Context
{Full ticket description and relevant comments}

## Investigation Findings
{Root cause + certainty markers from linear-ticket-investigator}

## Approved Proposal
- Root cause: ...
- Proposed fix: ...
- Affected files: ...
- Risk: ...

## Correlated Tickets
{If this PR resolves multiple tickets, list them all with IDs and titles}

## Requirements
- Branch: fix/{TICKET_ID}
- The PR description (created later by the executor) must reference Linear ticket(s) with "Fixes {TICKET_ID}"

Each planner returns one of:

Plan ready (confidence ≥ 90%) — worktree path + plan.md ready for execution.
Below gate (confidence < 90% after retries) — concerns surfaced for user decision.

Phase 5: Plan Review Gate (Optional)

By default, proceed straight to Phase 6 for any planner that returned "Plan ready". This is the fast path.

If any planner returned "Below gate", or if the user requested review plans at approval time, pause here:

## Plans Ready for Review

| # | Ticket | Confidence | Worktree | Action |
|---|--------|------------|----------|--------|
| 1 | SUP-123 | 95% (passed gate) | .agent/fix/SUP-123/ | execute |
| 2 | ENG-456 | 82% (below gate) | .agent/fix/ENG-456/ | review concerns |

For below-gate plans, list the concerns from the planner and offer:

refine — re-spawn the planner for another iteration
proceed — accept and dispatch executor anyway (NOT recommended)
stop — abandon this ticket

For plans that passed the gate, the user can optionally inspect plan.md before dispatch. Default: dispatch all gated plans without further prompting.

Phase 6: Parallel Execution (Fan-Out)

For each plan that cleared the gate (or was force-proceeded by the user), launch an aw-executor agent using the Agent tool with subagent_type: "aw-executor" and isolation: "worktree" pointing at the same worktree the planner used. Launch ALL executors in a single message.

The executor reads plan.md directly — it does not need a Decision Pack from this skill. A minimal prompt is enough:

Execute the plan at .agent/{branch}/plan.md in the current worktree.

The executor runs Phases 3–7 of autonomous-workflow: implement, test, document, open draft PR, watch CI.

Phase 7: Results & Linear Updates

As executors complete, present a final status table:

## Execution Results

| Ticket | Status | PR | Branch | Notes |
|--------|--------|----|--------|-------|
| SUP-123 | Done | #456 | fix/SUP-123 | All tests pass, CI green |
| ENG-456 | Done | #457 | fix/ENG-456 | Added 3 test cases |
| SUP-789 | Failed | — | fix/SUP-789 | Stuck-loop in Phase 4 |

For each successful PR, comment on the Linear ticket with the PR link via mcp__claude_ai_Linear__save_comment:

PR created: {PR_URL}
Branch: fix/{TICKET_ID}
Plan confidence: {X%}

Ask the user whether to update ticket state (e.g., move to "In Progress").

For failed executions, surface the error and suggested next steps (manual fix, re-plan, more context).

Customization

Domain Context

linear-ticket-investigator uses the project's domain context to ground its search. For monorepos, this dramatically improves investigation accuracy.

The agent looks for context in this order:

Top-level CLAUDE.md / AGENTS.md
Component-specific CLAUDE.md / AGENTS.md in directories the ticket points at
A project-shipped domain navigator skill (invoked via Skill())
Top-level README.md

To add a domain navigator for your project, create a skill named e.g. <project>-domain-navigator that:

Maps Linear labels (or ticket terminology) to component directories
Surfaces cross-component dependencies an outsider wouldn't infer
Lists where each domain's docs/runbooks live

The investigator will pick it up automatically as long as it's in the host project's installed skills. See the linear-ticket-investigator agent file for the exact lookup procedure.

Key Principles

Orchestrate, don't investigate or plan or implement — investigation lives in linear-ticket-investigator, planning in aw-planner, execution in aw-executor. This skill only coordinates and runs user-facing gates.
Two user gates: approval (Phase 3) and optional plan review (Phase 5) — both happen in main context where the user is. No checkpoint/resume machinery.
Decision Pack to planners, not to executors — planners need full investigation context to write plan.md. Executors just read plan.md.
Parallelize every fan-out — investigators, planners, and executors all launch in one message each.
The planner's confidence gate is authoritative — if it returns "Plan ready", the plan is safe to execute. Phase 5 only intercepts below-gate plans or user-requested review.
Correlate before planning — detect shared root causes and conflicts so one plan can resolve multiple tickets.
Handle partial failures at every phase — if some agents fail, present what you have and offer to retry.
User stays in control — every batch requires explicit approval at Phase 3. Information gaps must be resolved before that approval.

batch-linear-tickets