From a Jira ticket to a reviewed pull request

One Jira Cloud site

Connect one Jira Cloud site. From AOSplane you browse it with JQL, create issues, add comments, and start a session from an issue. The pull request comes back on GitHub, on a repository linked to the project with the GitHub App. This connection is Jira Cloud. The site does not describe Jira Data Center.

Linear has an extra door this page does not copy onto Jira. Inside Linear, the AOSplane agent answers on the issue and a reply continues the session. On Jira, the documented actions are browse, create, comment, and start. The gate after that start is the same one Linear uses. The Linear path and Rovo Dev, which is the other Jira-native agent people compare.

What the ticket needs to contain

JQL finds the work. It does not make a vague ticket provable. Write the outcome, the boundary, and the command that would show the criterion is true. Plan first turns that into a spec with a check on each acceptance criterion, and you approve the spec before the agent writes code. Without QA checks on the repository, Plan first stays switched off.

Spec is the default level. Brief is shorter and on every plan. PRD starts on Starter. Discovery starts on Team. The product manager only reads. Comments AOSplane posts back to the issue are comments, not a merge. The merge is still a person’s, on the GitHub pull request.

The same proof, either harness

Pick Claude Code or Codex for the agent. Claude Code reads CLAUDE.md. Codex reads AGENTS.md. Neither skips review or QA because of that choice. Review reads the diff. QA runs the checks. An agent saying the tests passed is not the verdict. Exit code 0 is. You set 1 to 5 tries, 3 by default. The last failure ends the session with no pull request.

The draft that opens carries QA’s result. With it, the team has the spec, the review notes, and what the task spent. That packet is the point of the page. Review and QA, split apart.

A cap for the ticket, not a shared pool

Rovo Dev draws on a credit allowance. Copilot draws on AI credits. AOSplane checks three limits before this ticket’s run: the organization, the project, and the agent. The tightest is a hard cap on the task. The task does not start if the reservation would cross it. A second ticket cannot spend what this one was refused.

Put a client or a product in its own project when the cap should differ. Agencies use that split. The numbers on the plans are on the pricing section. Claude Code’s own spend limits are a separate set of controls, and they still apply on the Anthropic side.