Linear Backlog

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 candidates in recorded backlog order.
2. Add every candidate that has no hard-conflict edge with a selected issue and has a safe worktree, child thread, runtime, data strategy, and proof path.
3. Record soft overlaps in conflict groups for merge arbitration.
4. Revisit every excluded candidate. If the exclusion is only caution, minor overlap, or expected merge work, include it.
5. Stop only when no excluded dependency-ready candidate can be added safely.

A one-ticket batch is valid only when hard conflicts, dependencies, or real capacity constraints force it. Record the reason.