Batch Linear Tickets

Batch Linear Ticket Resolver

Orchestrate parallel analysis and resolution of multiple Linear tickets — bug fixes and feature work. This skill owns batch-level concerns: per-ticket type classification, parallel fan-out of the right analysis tools, cross-ticket correlation, the user-facing approval gate, and Linear writeback.

Per-ticket investigation lives in linear-ticket-investigator. Per-ticket bug root-cause analysis is dispatched to the rca-investigator agent — it runs holistic-analysis (fix) + confidence (analysis) in an isolated context per ticket, so N bug analyses run in parallel and none of their verbose walkthroughs land in this orchestrator's window. Per-ticket planning lives in aw-planner. Per-ticket implementation lives in aw-executor. This skill wires them together for batch operation.

Architecture

Phase 1: Per-Ticket Analysis    → per ticket: classify type → investigator → (video-analyser if video flagged) → (rca-investigator if bug, carries confidence) | confidence(plan) if feature
Phase 2: Cross-Ticket Correlation → detect shared root causes, file conflicts, duplicates
Phase 3: Approval Gate          → user picks tickets to ship
Phase 4: Parallel Execution     → fan out aw-planner + aw-executor for approved tickets
Phase 5: Results & Linear Updates → status table + per-ticket PR comments

Phase 1's analysis runs once per ticket. Phase 4 dispatches aw-planner directly using the analysis from Phase 1.

---

Prerequisites

| Dependency | Purpose | Required? | |-----------|---------|-----------| | Linear MCP (mcp__claude_ai_Linear__* or mcp__linear-server__*) | Read tickets + labels, post PR comments | Yes | | linear-ticket-investigator agent | Per-ticket evidence extraction | Yes | | rca-investigator agent ([agents/rca-investigator.md](../../../agents/rca-investigator.md)) | Per-ticket bug root-cause analysis — isolated + parallel; carries confidence(analysis) in its Root-Cause Record | Yes (for bug tickets) | | holistic-analysis skill | Run transitively inside rca-investigator; in-context fallback if the agent is unavailable | Yes (for bug tickets) | | confidence skill | Feature-ticket gate scoring (bug score comes from rca-investigator) | Yes | | video-analyser skill | Analyse a video / screen-recording attachment flagged on a ticket (Step 1b.5) | Optional — skips silently if absent or no video flagged | | aw-planner + aw-executor agents (from [autonomous-workflow](../autonomous-workflow/SKILL.md)) | Phase 4 dispatch | Yes | | gh CLI | PR creation by aw-executor | Yes | | gw CLI | Worktree management (planner) | Recommended | | persistent-memory skill | batch-lessons self-improvement loop (read Phase 1, write Phase 5) | Optional — loop skips silently if absent | | Project domain-navigator skill | Investigation accuracy in monorepos | Optional — see [Customization](#customization) |

---

Rules

| Rule | When it loads | |------|---------------| | [ticket-type-classification](./rules/ticket-type-classification.md) | Phase 1 — classify each ticket as bug or feature | | [cross-ticket-correlation](./rules/cross-ticket-correlation.md) | Phase 2 — detect shared root causes, duplicates, conflicts | | [batch-approval-ux](./rules/batch-approval-ux.md) | Phase 3 — summary table format, status values, approval commands | | [self-improvement-loop](./rules/self-improvement-loop.md) | Cross-cutting — batch-lessons fast tier (read Phase 1 / write Phase 5) + promotion to diagnose | | [diagnostic-surface](./rules/diagnostic-surface.md) | Consumed by /create-skill diagnose batch-linear-tickets — phase model, guards, hard invariants |

> Investigation rules live in linear-ticket-investigator. > Bug root-cause rules live in holistic-analysis, dispatched via the rca-investigator agent. > Planning and execution rules live in aw-planner and aw-executor. > This skill only owns batch-level fan-out, classification, and the user-facing approval gate.

---

Arguments

Parse $ARGUMENTS for ticket identifiers and the optional --type flag.

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

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

Type flag (optional)

| Flag | Effect | |------|--------| | --type=auto (default) | Classify each ticket via Linear labels (see [ticket-type-classification](./rules/ticket-type-classification.md)) | | --type=bug | Force every ticket in the batch to bug pipeline (investigator + holistic-analysis) | | --type=feature | Force every ticket in the batch to feature pipeline (investigator only) |

The flag applies to the whole batch. For mixed batches with no labels, surface the unclassified tickets as Needs Info and ask the user to either tag them in Linear or re-run with explicit --type.

---

Phase 1: Per-Ticket Analysis (Fan-Out)

For each ticket, run the analysis pipeline appropriate to its type. Launch homogeneous calls in a single message so they run in parallel.

Step 1.read — Read prior batch lessons

Before classifying, load batch-lessons so prior classification and correlation misfires bias this batch:

Skill("persistent-memory", "read batch-lessons --tier home")     # skips silently if not installed

Match lessons by label set / ticket-type / affected-area; apply as advisory inputs to classification (Step 1a) and correlation (Phase 2). Lessons never override an explicit --type flag or auto-approve a Needs Info ticket. Full contract: [rules/self-improvement-loop.md](./rules/self-improvement-loop.md#read-lessons-phase-1). (The planning / implementation phases inherit the aw-lessons loop automatically via the aw-planner / aw-executor fan-out in Phase 4 — no action needed here.)

Step 1a — Classify

If --type=bug or --type=feature: every ticket inherits that type. Skip to Step 1b.

Otherwise (--type=auto):

1. Fetch each ticket's labels via mcp__claude_ai_Linear__get_issue (or the equivalent

mcp__linear-server__* tool). Launch all fetches in one message for parallelism.

1. Apply the classification rules in

[ticket-type-classification](./rules/ticket-type-classification.md):

• Has any label in {bug, defect, incident, regression, hotfix, fix, kind/bug} → bug
• Otherwise → feature
• No labels at all → unknown (status becomes Needs Info)

Record the type per ticket. Surface any unknown tickets to the user before continuing.

Step 1b — Dispatch the investigator (every ticket)

Dispatch the linear-ticket-investigator agent for every ticket — bug or feature. Launch all investigator calls in one message for parallelism.

The investigator returns an Evidence Record (problem description, affected code, certainty markers, information gaps). It does not implement; it investigates. It also flags any video / screen-recording attachment in the record's Video evidence field — but it cannot analyse the video (no Bash). That is Step 1b.5's job.

Step 1b.5 — Analyse flagged video attachments

For every ticket whose Evidence Record has Video evidence: Present, run the video-analyser skill before analysis (Step 1c). A screen recording usually carries the clearest reproduction steps and exact error state available — treating it as first-class evidence materially improves the downstream root-cause analysis and confidence score.

For each such ticket, pass the Linear ticket URL so video-analyser's own Linear resolution obtains an authenticated (pre-signed) download URL via MCP:

Skill("video-analyser", "")

Because video-analyser shells out to ffmpeg, these calls are not parallelisable via a single message the way the agent dispatches are — run them sequentially (one ticket's video at a time). For a ticket with multiple distinct videos, re-invoke with each direct video URL from the Video evidence list.

Fold the structured video findings (errors, UI state, inferred reproduction steps) into that ticket's Evidence Record before Step 1c, so rca-investigator sees them. If the video-analyser skill is not installed, note the un-analysed video URL in the Evidence Record and continue — do not block the batch on it.

Step 1c — Dispatch rca-investigator (bug tickets only)

For tickets classified as bug, dispatch the rca-investigator agent with the Evidence Record from Step 1b:

Task(subagent_type="rca-investigator", prompt="")

Launch all bug-ticket rca-investigator calls in one message so the analyses run in parallel — this is exactly the case where parallelism makes sense (N independent tickets, no shared state). Each agent runs holistic-analysis (fix) + confidence (analysis) in its own context and returns a compact Root-Cause Record (root cause, causal chain, evidence, ruled-out alternatives, confidence score, fix direction). The verbose 8-phase walkthrough never reaches this orchestrator.

If the rca-investigator agent is not available in the host project, fall back to running Skill("holistic-analysis", "fix") + Skill("confidence", "analysis") in-context per bug ticket (serial, non-isolated) — the same analysis, without the isolation/parallelism benefit.

Feature tickets skip this step — the investigator's Evidence Record (intent + acceptance criteria + affected code) is the analysis output. Root-cause analysis is bug-shaped and would mis-frame feature work.

Step 1d — Gate per ticket

• Bug tickets — the confidence(analysis) score is already in the Root-Cause Record from

Step 1c (it scored evidence strength, root-cause certainty, fix confidence). Do not re-run it; read it from the record.

• Feature tickets — run Skill("confidence", "plan") in-context. It scores completeness,

feasibility, and ambiguity of the proposed approach captured in the investigator's Evidence Record.

Status mapping (same shape for both types, different source skill):

| Status | Bug source | Feature source | Approvable? | |--------|-----------|---------------|-------------| | Ready | confidence(analysis) ≥ 90% | confidence(plan) ≥ 90% | Yes | | Needs Review | confidence(analysis) 70–89% | confidence(plan) 70–89% | Yes (with warning) | | Needs Info | Information gap from investigator | Acceptance criteria missing or unclassified | No | | Stopped | confidence(analysis) /plan.md in the current worktree.

Lesson-write serialization: do NOT write to shared lesson scopes (aw-lessons) during this run — return your lesson candidates in your result payload; the orchestrator writes them serially after the fan-out completes.

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

**Lesson-write serialization (batch fan-out contract).**
Parallel executors return lesson candidates in their result payload; the orchestrator writes all lessons serially after fan-out completes.
Executors MUST NOT write to shared lesson scopes directly during fan-out.
Concurrent writes to `~/.agent-memory/aw-lessons/INDEX.md` can interleave; the serial post-fan-out write (one `Skill("persistent-memory", "write aw-lessons --tier home --auto")` per candidate batch, in Phase 5) is the only safe path.

---

## Phase 5: Results & Linear Updates

As executors complete, present a final status table:

```markdown
## Execution Results

| Ticket | Type | Status | PR | Branch | Notes |
|--------|------|--------|----|--------|-------|
| SUP-123 | bug | Done | #456 | fix/SUP-123 | Confidence 95%, all tests pass |
| AI-1165 | feature | Done | #457 | feat/AI-1165 | Confidence 92%, 3 components updated |
| SUP-789 | bug | 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: {BRANCH}
Type: {bug | feature}
Phase 1 confidence: {X%}
Plan confidence: {Y%}

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

Step 5.write — Capture batch lessons

When the batch's own orchestration misfired, write a lesson so the next batch does better:

Skill("persistent-memory", "write batch-lessons --tier home --auto")     # skips silently if not installed

Capture: a ticket whose type was wrong (label set → correct type), a cross-ticket conflict Phase 2 correlation missed, or a chronically Needs Info ticket shape. --auto skips consent, not the privacy pre-flight. A lesson recurring seen_count >= 3 becomes promotion-eligible — see [rules/self-improvement-loop.md](./rules/self-improvement-loop.md#write-lessons-phase-5).

---

Self-Improvement

/batch-linear-tickets improves across batches through a two-tier loop (full contract: [rules/self-improvement-loop.md](./rules/self-improvement-loop.md)).

• Inherited for free: the planning and implementation phases use the

aw-lessons loop because Phase 4 dispatches aw-planner / aw-executor. Serialization contract: parallel executors return lesson candidates in their result payload; the orchestrator writes all lessons serially after fan-out completes. Executors MUST NOT write to shared lesson scopes directly during fan-out.

• Fast tier (this skill): batch-lessons — read at Phase 1, written at

Phase 5 — covers batch-level orchestration only (type classification, cross-ticket correlation, chronic Needs Info). Advisory; skips silently if persistent-memory is absent.

• Slow tier: a lesson recurring seen_count >= 3 (or tagged structural)

is promoted via /create-skill diagnose batch-linear-tickets, which reads the [diagnostic surface](./rules/diagnostic-surface.md) and batch-lessons history and emits a confidence-gated diff (commonly into ticket-type-classification.md / cross-ticket-correlation.md) behind the confidence(analysis) ≥ 90 % + user-approval gate.

---

Customization

Domain Context

linear-ticket-investigator uses the project's domain context to ground its evidence extraction. For monorepos this dramatically improves the accuracy of the Affected-Code table.

The agent looks for context in this order:

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

To add a domain navigator for your project, create a skill named e.g. -domain-navigator that maps ticket terminology to component directories. The investigator picks it up automatically as long as it is in the host project's installed skills.

See the [linear-ticket-investigator](../../../agents/linear-ticket-investigator.md) agent file for the exact lookup procedure.

Type Classification Overrides

If your workspace uses non-standard labels (e.g., type:bug instead of bug), edit [ticket-type-classification](./rules/ticket-type-classification.md)'s default label list or always pass --type=bug / --type=feature explicitly.

---

Key Principles

1. Type-aware orchestration. Bugs run through investigator + holistic-analysis. Features run

through investigator only. Both gate on confidence (different modes). Phase 4 and Phase 5 are type-agnostic.

1. Single user gate (Phase 3 approval). No checkpoint/resume machinery. Below-gate plan

surfacing in Phase 4 is per-planner, not a separate batch gate.

1. Analyse once, execute once. Phase 1 is the only place analysis runs per ticket. Phase 4

dis

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mthines
• Source: mthines/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.