Automate Linear tickets into GitHub pull requests
Assign the issue to Sinatra the way you would assign a teammate. It picks the ticket up as an agent session, figures out which repository you meant, and comes back with a pull request. You stay in Linear the whole time.
Handing over a ticket
There are two ways in, and they behave identically once the run starts. Assign the issue to Sinatra, or @-mention it in a comment. Both open a Linear agent session, which is the surface Sinatra reports back into.
Nothing else starts a run. Moving a ticket into your in-progress column, adding a label, editing the description: none of it triggers anything. That is deliberate. A tracker where any edit could spend money on an agent run is a tracker nobody wants to touch.
Working out which repository you meant
This is the part that only exists on the Linear side. A GitHub issue already knows its repository; a Linear ticket does not, and most teams point one Linear workspace at several repositories.
If the issue body contains a line reading Repo: owner/name, that wins outright and no inference happens. Otherwise Sinatra reads the title, description, labels, project and team, and matches them against the repositories you have enabled, using each repository's own agent instructions file as context for what it is for. If it still cannot tell, the run stops and asks you to add the Repo line. It does not pick one and hope.
What you see while it works
Sinatra reports into the Linear agent session rather than into a comment thread, so its thinking, its actions and its final answer render in Linear's own agent UI instead of burying the issue in bot noise.
The ticket moves into your started column when work actually begins, and to Planning while it is planning if your team has a state by that name. Sinatra looks for a state literally named In Progress and falls back to the first started-type state your team defines, so if you have renamed yours, check which one it picks. Those are the only two transitions it makes: it never moves a ticket to Done, because what happens after review is your team's convention and not something an agent should assume. When the pull request exists, it is attached to the issue as a sidebar link, refreshed rather than duplicated if later iterations push more commits.
Approving the shape before the code
For anything vague, Sinatra writes a requirements document first and posts it as a comment on the ticket. For anything well specified, it writes a plan. Either way the document is a comment thread you can argue with, not a mutation of your issue description.
Reply in that thread to approve or to ask for changes; Sinatra reads the intent of your reply rather than looking for a magic word. Approving a requirements document moves it to planning, never straight to code. Approving a plan moves it to implementation and collapses the plan comment so the ticket stays readable. Reply in the wrong thread and it tells you which one to use instead of acting on it. Reviews wait 24 hours before the run gives up.
Steering, restarting and stopping
A follow-up comment on a live run steers it: same sandbox, same branch, same draft pull request. Ask for something fundamentally different and Sinatra recognises it as a restart and starts clean. If it is unsure which you meant, it continues rather than throwing away work, because losing an hour of context to an ambiguous sentence is the worse failure.
To stop a run, use the stop control on the agent session, or move the issue to Canceled or Duplicate. Moving it to Done ends the run too, but records it as completed rather than cancelled.
Setting it up
An owner or admin installs the Linear app, which makes Sinatra assignable and mentionable in your organisation.
One person links their Linear account. That connection is what lets the agent read ticket detail from inside its sandbox, so it sees the full issue rather than just a title. Everyone else can trigger runs without linking anything.
Sinatra only considers repositories you have explicitly enabled, which is also what makes repo inference tractable.
Pick something small and real. Watch it in the agent session.
Common questions
How does Sinatra know which repository a Linear ticket belongs to?
A Linear ticket doesn't carry a repository, so Sinatra works it out. Add a line reading 'Repo: owner/name' to the issue and that wins outright. Otherwise a classifier infers the target from the title, description, labels, project and team, cross-referenced against the repositories you've enabled. If it still can't tell, the run stops and asks you to add the Repo line rather than guessing.
Does Sinatra change the status of my Linear issue?
It moves the ticket into your started column when work begins, and to Planning while it is planning if your team has a state by that name. It looks for a state named In Progress and otherwise takes the first started-type state your team defines. It never moves a ticket to Done. Closing the loop stays with you and whatever your team already does on merge.
Can I stop a Linear run once it has started?
Yes. Use the stop control on the agent session, or move the issue to Canceled or Duplicate, and the run is cancelled. Moving it to Done also ends the run, but records it as completed rather than cancelled. Replying in the thread instead lets you steer the existing run without starting a new one.
Does everyone on the team need to connect their Linear account?
No. One member of the workspace connects Linear, and that connection is what lets the agent read tickets from inside its sandbox. Anyone in your Linear organisation can then trigger a run.
Working in GitHub instead? The GitHub issue workflow is triggered by a label and reports into the pull request itself. Full configuration reference is in the documentation.