How to Turn a Linear Issue into a Cursor Agent PR

The core of a Linear → Cursor agent PR handoff is turning the issue body into an executable work packet, not a readable ticket. With Linear connected, you can assign the issue to Cursor or mention @Cursor in a comment to start a Cloud Agent. The agent reads issue context, opens a PR when done, and reports status back in Linear.

This post covers only what to copy/enrich from the issue, a PR description template, and when to request review. It does not retell multi-agent branch ownership or path-lock rules. No pricing or personal reviews. Grounded in the Cursor Linear integration and Cloud Agents.

What do you copy from the issue?

One-line answer: Bundle title, goal, acceptance criteria, repro/verify commands, scope paths, non-goals, links, and repo/base hints. Drop novel-length background and secrets.

Minimum packet for the agent (or a local Agent prompt):

FieldWhyCopy / enrich tip
Issue ID + titleTrace PR/commits back to LinearKeep ENG-1234: … on the goal line
One-sentence goalWhat is different when doneVerb-first: “stabilize flaky login”
Acceptance criteria (AC)Human pass/failObservable: test, UI, one log line
Repro / verify commandAgent Done conditione.g. npm test -- path must exit 0
Scope / out of scopePrevent drive-by editsAllowed paths / do-not-touch
LinksCompress contextFigma, failing CI, related PR, screenshots
Repo / baseAvoid wrong clone[repo=owner/name], [branch=main]

Even when you delegate in Linear, an empty body yields shaky output. Fill the fields before assign, or paste an enrichment packet in the @Cursor comment. Docs support [key=value] in issue text or comments.

Goal: ENG-1234 — <one sentence: state when done>
Acceptance:
  - <observable criterion 1>
  - <observable criterion 2>
Repro / Verify (must exit 0 when done):
  <command>
Scope: <paths>
Out of scope: <list>
Links: <Linear URL, failing CI, design>
Hints: [repo=owner/repo] [branch=main]
Do not: push secrets, widen scope, force-push shared branches

Do not copy

  1. Secrets, tokens, personal data — keep in Cloud Secrets / local keychain; name only in the issue.
  2. Full Slack threads — summarize decision, repro, and rejected options.
  3. Vague “make it cleaner” — turn AC into commands or checklists.
  4. Every failed attempt — two or three lines of “tried / why failed” is enough.

The same packet works for a local Agent paste. Linear delegation leaves it on the issue; local puts it in the first chat message. Shape is identical.

What is the PR description template?

One-line answer: Fixed sections for Linear ID, summary, AC checklist, tests, screenshots/logs, risk, and out of scope. Let the agent draft; a human polish once before reviewers see it.

Instruct the agent: “Fill this PR body template.”

## Linear
- ENG-1234 — <issue title>
- Link: <Linear URL>

## Summary
- <what / why in 2–4 bullets>

## Acceptance checklist
- [ ] <AC1 — how to observe>
- [ ] <AC2>

## Test plan
- Commands run: `<…>`
- Result: pass / fail + one line
- Manual: <UI / env if needed>

## Risk & rollback
- Risk: <data / API / migration>
- Rollback: <revert unit / feature flag>

## Out of scope
- <explicitly not in this PR>

## Notes for reviewers
- <tricky files / intentional tradeoffs>

Fill rules:

  1. Summary is not a file list — intent and boundaries only.
  2. AC checklist maps 1:1 to the issue AC; missing items become “follow-up issue.”
  3. Test plan lists commands actually run — “tested” alone forces another question.
  4. Redact secrets / internal URLs or replace with an internal doc link.
  5. If the agent opened the PR, confirm Linear status/PR link, then overwrite an empty body with the template.

Prefer titles like ENG-1234: <short outcome> so Linear and GitHub stay searchable. Skip implementation trivia in the title.

When do you request review?

One-line answer: When the PR body has AC + test plan, CI (or the agreed minimum checks) is green (or failures are explained), and the diff stays in issue scope. Do not ping reviewers just because “the agent opened a PR.”

Pre-request checklist:

  1. Issue AC ↔ PR checklist say the same thing.
  2. No out-of-scope files — split or justify under Out of scope.
  3. Reviewer can re-run the verify command as written.
  4. Any failing checks have a “why ignore / follow-up” note in the body.
  5. No secrets, debug dumps, or PII in the diff.

Wait when:

  • The agent is still iterating on follow-up @Cursor instructions.
  • AC is subjective (“UI feels better”) with no screenshot or criterion.
  • Wrong repo/base because labels/[repo=…]/dashboard default were unset — fix that first.
  • Body is empty except a Linear link.

Request now when:

  • AC boxes are filled and the minimum tests pass.
  • Risk/rollback has at least one line.
  • Notes call out intentional tradeoffs for the reviewer.

For review feedback, paste a summary into a Linear @Cursor comment or fix locally. Inline PR comments are not always visible to the agent—restate the fix list in Linear or chat. Approve and merge stay with humans (or your team gate).

Wrap-up

Linear → Cursor agent PR is issue packet (goal, AC, verify, scope, repo hints) → templated PR → request review after AC/verify. The assign button is not enough; fixing the copy/enrich fields is the lever. Parallel branch rules belong elsewhere—this post is the handoff axis only.

Sources