From a Linear issue to a reviewed pull request

Two ways the issue starts the session

Connect Linear to the workspace and link the GitHub repositories with the GitHub App. Then either start a session from the issue, or hand the issue to the AOSplane agent inside Linear. That agent answers on the issue. A reply there continues the session. The code change still comes back as a pull request on GitHub. The run stays tied to the issue it came from.

Codex takes the same path as Claude Code. The harness is a choice on the agent. The gate in front of your team is not. How this differs from Linear’s own agent, and Claude Code on these tickets specifically.

What you approve before code

Plan first is the mode that puts a spec in front of a person before the agent writes. The product manager can only read: code search on the project’s repositories, the issues in them, and, on Starter and up, the knowledge base. It writes the problem, the goal, and acceptance criteria, each with a check. Spec is the default. Brief is shorter. PRD is on Starter and up. Discovery is on Team and up. You approve it, or you send it back, up to five revisions. A plan nobody decides on expires after 24 hours and the run ends.

The issue should say the outcome and the boundary, the way Linear’s own docs ask for a well-scoped issue. Name the command that proves each criterion if you know it. Plan first stays off until the repository has QA checks. The console shows that, and links to Repository setup. Free includes Brief and Spec, 10 product-manager specs a month. Starter includes 50, Team 200. A Spec counts double a Brief.

What your team is handed

After you approve the spec, the session’s agent builds in that task’s sandbox. Review reads the diff and can send it back. QA runs the repository’s checks and one command per acceptance criterion. Exit code 0 passes. A failing check goes back with the command and the end of its output. You choose 1 to 5 tries. 3 is the default. If the last try fails, there is no pull request.

When they pass, the gate opens a draft pull request with QA’s result on it. The spec, the review notes, and the cost of the task are the rest of what the team is looking at. Agents cannot push. A person merges, in AOSplane or on GitHub. The review and QA page separates the two proofs: one reads, one runs.

The cap on that task

Before the run, AOSplane reserves budget against the organization, the project, and the agent. The tightest limit is a hard cap on the task. Over it, the task does not start. Runs already going are not cancelled by a later check. That is a different control from a workspace credit balance several sessions share. Setting the cap, including the limits Claude Code already has on its own.

The Jira version of this loop is the same gate from a Jira ticket. Nothing in the review or the cap changes because the tracker did. Pricing.