aq.dev / use cases / linear-to-pr

From Linear issue to PR

In AQ, a Linear issue becomes agent work by adding one label. Labeling an issue ai-task creates a workspace for it (an isolated git worktree on its own branch) and moves the issue to In Progress. An engineer opens the workspace, drives the agent with the issue's context, and the resulting PR is tracked on the workspace. When the issue is marked Done, its workspace closes. The board you already run stays the source of truth.

This matters because the alternative is double bookkeeping: a sprint planned in Linear, executed in scattered terminals, and reconciled by hand at standup. Wiring intake to the tracker removes the reconciliation, not the humans: nothing launches by itself, and every agent run is started and steered by a person.

Sprint mechanics

The issue is the prompt's context

The engineer opens the workspace with the issue's requirements at hand and gives the agent a scoped brief. Because the workspace was created from the issue, the link between "what was asked" and "what the agent is doing" is structural, and anyone reviewing later can trace PR to workspace to issue without a search.

Review with the sprint's cadence

The PR the agent opens goes through your normal GitHub review, with the workspace as review context: live preview for behavior, terminal scrollback for reasoning, comments that go back to the agent as prompts. The review pattern is detailed in reviewing AI agent work, and the integration reference is in docs: Linear integration.

Frequently asked questions

Does labeling an issue launch an agent automatically?

No. The label creates the workspace and moves the issue to In Progress; a person opens the workspace and starts the agent deliberately. AQ wires intake to the tracker without taking humans out of the loop.

What happens if we reassign the issue in Linear?

The workspace follows: reassigning the issue re-attributes its workspace to the new assignee, so ownership on the board and ownership of the work stay consistent.

Can several labeled issues run at once?

Yes. Each issue gets its own workspace in an isolated git worktree on its own branch, so parallel issues cannot interfere with each other's files.

What closes the workspace?

The board does. Moving the issue to Done or Canceled closes its workspace, so cleanup follows the process you already run instead of being a separate chore.