Turning Linear tickets into GitHub PRs with an autonomous agent

Every team has a backlog of small, well-defined tickets. "Add pagination to the users endpoint." "Fix the timezone bug in the export." "Write tests for the retry helper." None of them are hard. All of them cost a context switch: you stop what you're doing, load the repo back into your head, make the change, wait for CI, open the PR.

Sinatra does that part for you. You hand it a Linear or GitHub issue, and a few minutes later there's a pull request waiting for review. Here's what happens in between.

The short version

You hand it an issue. Sinatra reads it, opens a branch and a draft pull request, writes the code, and runs your tests. You review that PR the way you'd review a teammate's. If something's off, you leave a comment and it revises.

That's the whole loop. Everything below is just detail.

Handing the agent a Linear ticket or GitHub issue

In Linear, assign the issue to Sinatra the same way you'd assign a person, or mention @sinatra in a comment. On GitHub, add the Sinatra label to the issue. Sinatra provisions the label on the repos you enable.

Either way, the issue is the spec. A clear title and a couple of sentences of context are usually enough. If the ticket is vague, Sinatra tells you what it's assuming before it starts writing, so you can correct it early instead of after the code exists.

What happens in the sandbox

Once it picks up the issue, Sinatra starts an isolated sandbox and checks out your repository into it. Everything from here on happens in that sandbox, not on your machine and not on your main branch.

Inside, it works the way you would:

• reads the parts of the codebase the ticket touches
• creates a branch
• makes the change
• runs the test command you've configured

If the tests fail, it reads the failure and tries again before it asks you to review. The sandbox is shut down when the run finishes.

Reviewing the pull request

Sinatra's pull request opens as a draft while it works. When the work is done, it marks the PR ready for review, with a description of what it changed and why. From your side it looks like any other PR: a diff, a description, and check results.

You review it. If it's good, you merge it. If it isn't, you leave a review comment ("use the existing helper instead of a new one," say, or "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. You are never handed a black box. You get a diff you can read and change.

Using your own models and keys

You choose the model. Bring your own Anthropic (Claude) or OpenRouter key, or connect a ChatGPT subscription you already pay for, and Sinatra runs the work on it. Your keys are stored encrypted and used only to run your tasks.

When you use your own key or subscription, there's no markup on tokens, and your code goes through your own provider under your terms.

Where you stay in control

A few things keep this from turning into a free-for-all:

• The pull request is the gate. Nothing reaches your main branch until a person merges it.
• Scope stays on the ticket you assigned. Sinatra opens one PR for it and keeps the change focused.
• The behavior is yours to set. A small .sinatrarc.json file in your repo controls the model, whether phases like planning run, and how the sandbox is set up.

Checked into your repo, that config can be as short as this:

{
  "agent": { "model": "opus" },
  "planning": { "enabled": true }
}

When it's a good fit

Sinatra earns its keep on tickets that are clear but tedious: bug fixes with a known cause, small features, missing test coverage, mechanical refactors, dependency bumps. It frees you to spend your attention on the design work and the hard calls that actually need a person.

Assign it the next small ticket in your backlog and see what comes back. The short product version of this workflow is on the Linear tickets to PRs page. You can start for free, or read the docs to wire up your repo.