/linear-backlog

name: linear-backlog
description: Run a scoped Linear backlog autonomously as a sequence of maximal safe parallel batches by composing orchestrator, autogoal, and task. Use when the user wants Codex to execute ordered Linear issues without prompting for each next batch while parallelizing every dependency-ready ticket that lacks a hard conflict.

Linear Backlog

Run a frozen Linear queue as serial batches with parallel execution inside each batch. Keep the parent as controller; send every implementation issue through `orchestrator`, `autogoal`, and the repo's `task` skill.

Required Capabilities

Require all of these before mutation:

• Linear issue read and write tools.
• `$orchestrator` with durable Codex child-thread tools.
• `$autogoal` and its goal tools.
• The destination repo's `$task` skill and AGENTS instructions.
• Git and the repo's normal PR and merge tooling.

If a capability is missing, report the exact dependency. Never replace durable child threads with hidden sub-agents or fake Linear state transitions with comments.

Commands

• `$linear-backlog run <scope>`: execute the queue in maximal safe parallel

batches.

• `$linear-backlog status`: report counts, active batch and lanes, conflict

groups, blocked issues, and the next candidate batch.

• `$linear-backlog stop`: stop after parking every active lane safely and

recording resumable state.

Scope may be a Linear project, cycle, label, saved view, or explicit issue list. If the prompt and current context do not identify exactly one scope, ask one short question before mutation.

Non-Negotiable Contract

• Keep exactly one batch active at a time.
• Run every safe lane in that batch concurrently.
• Do not start the next batch until every lane in the current batch is

queue-terminal and the batch join is recorded.

• Make each batch inclusion-maximal: no remaining dependency-ready issue may be

added without a hard conflict or exceeding proven safe capacity.

• Never impose an arbitrary lane cap.
• Treat minor file overlap or an expected small merge conflict as a conflict

group, not an automatic reason to serialize.

• Do not implement product code in the parent.
• Do not ask the user to say `continue` between batches.
• Do not widen an issue beyond its Linear description, acceptance criteria,

linked source, and repo policy.

• Freeze queue membership at startup unless the user explicitly asks for

continuous intake. State, dependencies, and ordering may still change.

• Re-read Linear after every issue transition and before planning each batch.
• Never invent missing issues, acceptance criteria, or product decisions.

Queue-terminal means one of:

• merged, verified, and moved to the team's completed state;
• canceled by an authorized source;
• blocked with evidence, an owner or missing decision, and a concrete next

action.

Opening a PR, passing tests, or finishing a plan is not queue-terminal by itself.

Start The Parent Run

1. Turn `$orchestrator on` and record the mode in parent status. 2. Use `$autogoal` to create one parent goal for the frozen queue. 3. Define the parent completion threshold as:

• every frozen issue id is queue-terminal;
• every batch has joined;
• no child is still mutating code;
• every completed issue has verified merge and Linear state evidence;
• blocked count is zero.

If blocked items remain after all eligible work is exhausted, close the loop as blocked under `$autogoal`; do not call the queue complete. 4. Create a queue ledger:

| Batch | Order | Issue | State | Dependencies | Conflict group | Child | Branch / PR | Proof | Blocker / owner | Next |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

5. Record total, completed, blocked, active, and remaining counts after every transition.

The parent goal owns queue and batch completion. Each child owns a separate issue-scoped autogoal.

Build The Queue

1. Resolve the Linear team and its real workflow states. 2. Query the requested scope and read every candidate issue in full, including description, priority, project or cycle, state, labels, links, parent-child relationships, and blocking dependencies. 3. Exclude completed and canceled issues from runnable work, but keep them in the frozen ledger as already terminal. 4. Preserve explicit Linear ordering when exposed. 5. If no explicit order is available, sort dependency-ready issues by priority, then oldest creation time. Record this fallback once. 6. Keep dependency chains visible. A dependency and its dependent issue can never share a batch. 7. Never treat a broad project description as issue acceptance criteria unless the issue explicitly adopts it.

Plan A Maximal Safe Batch

Build a fresh conflict graph from every dependency-ready, non-terminal issue. Use issue source, likely owners, repo structure, current branches, runtime and data requirements, and prior batch evidence. Lexical file guesses alone are not proof.

Create a hard-conflict edge only when concurrent execution would be unsafe or would invalidate proof, such as:

• a dependency relation;
• the same migration, schema contract, generated artifact, or exclusive config

owner;

• overlapping destructive or proof-breaking writes to the same data;
• the same exclusive runtime, port, environment, credential, or deployment

surface when it cannot be isolated;

• the same security or authorization policy mutation;
• source-backed evidence that both tickets must change the same unmergeable

lines or API contract in incompatible ways.

Do not create a hard-conflict edge merely because tickets:

• belong to the same product area or package;
• touch adjacent components;
• may both update a barrel, lockfile, docs index, or generated summary;
• may produce a small normal merge conflict;
• use the same read-only service or test suite;
• have vague keyword overlap without source-backed ownership evidence.

Select the batch:

1. Start with