How to assign a Linear issue to an AI agent (and get a PR back)

You can assign a Linear issue to an AI agent the same way you assign it to a person, and a few minutes later there's a pull request waiting for review. This tutorial walks that loop end to end using Sinatra, which we build, so read it knowing that. The shape of the workflow (connect the agent, write a clear ticket, assign or mention it, review the PR) is the same across most agents on Linear's platform, so the steps transfer even if you're evaluating something else. If you want the conceptual version of what happens during a run, the companion post is Turning Linear tickets into GitHub PRs, and the product page for the workflow is Linear tickets to PRs. This one is just the steps.

Step 1: connect the agent to Linear and GitHub

Sign in to Sinatra and connect your Linear workspace and the GitHub repositories you want it to work in. It only sees the repos you enable. Both connections are short OAuth flows; the permission details and per-repo configuration are in the docs, so this post won't duplicate them. (Linear is the trigger in this tutorial. For work that starts as a GitHub issue instead, you add the Sinatra label to the issue; that flow has its own page.)

One thing worth doing during setup: configure the test command for each repo (a small .sinatrarc.json file checked into the repo). The agent runs that command in its sandbox and uses the result to decide when its PR is ready for review, so a real test command is the difference between "compiles" and "works".

Step 2: write a ticket the agent can implement

The issue is the spec. Everything the agent knows about your intent lives in the title, description, and comments, so the quality of the PR tracks the quality of the ticket. Three rules cover most of it:

1. State the outcome, not the vibe. For a bug: what happens now, what should happen, and how to reproduce it. For a feature: acceptance criteria concrete enough to test against ("the export uses the user's timezone" beats "fix the dates").
2. Name the surface if you know it. "The timezone bug is in the CSV export endpoint" saves the agent a search and cuts the odds it fixes the wrong thing.
3. Put constraints in the ticket, not in your head. "Use the existing date helper", "don't change the public API", "add a test for the DST case": if a reviewer would say it later, say it in the ticket now.

You don't need a perfect ticket. If yours is vague, the agent will tell you what it's assuming before it writes code (more on that in step 4). But two minutes here pays for itself at review time.

Step 3: assign the Linear issue to the AI agent

Open the issue, click the assignee field, and pick Sinatra from the list, exactly as you would a teammate. If you'd rather keep a person as the assignee, mention @sinatra in a comment instead. A comment mention is also where one-off instructions go ("branch off release-2.4, not main").

That's the whole trigger. There's no separate dashboard to go start a job in; the issue is the interface.

Step 4: watch the issue while it works

Sinatra posts progress into the issue as it goes, so you can see where a run is without leaving Linear. What happens first depends on the ticket:

• A clear, small ticket goes straight to implementation.
• A well-specified but nontrivial ticket gets a short plan posted to the issue first.
• A vague ticket triggers a brainstorm: the agent writes up the requirements it thinks you meant and posts them as a comment for approval before any code exists. Reply in the thread to correct or approve, and it proceeds from the corrected version.

That last case is the one that saves the most time. The cheapest place to catch "that's not what I meant" is before the diff exists, not after.

During implementation, the agent works in an isolated sandbox: it checks out the repo, creates a branch, makes the change, and runs the test command you configured. If tests fail, it reads the failure and fixes it before asking for your review.

Step 5: review the pull request

When the run finishes there's a pull request linked from the issue: a branch, a readable diff, a description of what changed and why, and your CI running against it like on any other PR.

Review it the way you'd review a teammate's work. The PR is the gate: nothing reaches your main branch until a person merges it, so the worst case for a bad run is a closed PR and a few minutes of reading.

Step 6: ask for changes and watch it revise

If the PR isn't right, do what you'd do with a person. Leave a review comment on the line ("use the existing helper instead of a new one", "this needs a test for the empty case") and reply to Sinatra in the thread. It picks the comment up and pushes a revision to the same branch, and the PR updates in place. You don't re-file the ticket or restart anything; the review conversation is the interface for iteration.

What to try first

Start with a small bug fix with a known cause. It's the best first test because you can judge the result in minutes: you already know roughly what the fix should look like, so the PR either matches your mental model or it doesn't, and either answer teaches you something. Good second tickets are missing test coverage for an existing module, a mechanical refactor, or a dependency bump with a changelog to follow.

Hold back the open-ended work. A ticket with no acceptance criteria is a poor assignment for any agent (the brainstorm step softens this, but a person still has to approve the direction), and anything that needs access to production systems is out of scope by design.

One assigned ticket and one honest PR review will tell you more than any writeup, including this one. Start for free and try it on the next small bug in your backlog, or read the docs first if you want the setup details.