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. 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. It never moves a ticket to Done, because what happens after review is your team's convention. When the pull request exists, it is attached to the issue as a sidebar link, refreshed rather than duplicated if later turns push more commits.
Approving the shape before the code
Ask Sinatra to discuss requirements or write a plan before changing code. You do not need to enable a separate phase in repository or personal settings. The agent replies in the conversation, where you can ask questions, request changes, or tell it to proceed.
Code work still requires task admission. A stopped conversation can resume on your next message; a run that goes idle for 24 hours ends without deleting its saved workstream or documents.
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.
Anyone who assigns tickets to Sinatra needs to be a member of your Sinatra workspace. Sinatra matches their Linear account by verified email; if it cannot, they link their Linear account once from the dashboard. The agent itself reads ticket detail through the Linear app, so it sees the full issue rather than just a title, whoever delegated.
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. 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?
Not usually. The agent reads tickets from inside its sandbox through your workspace's Sinatra Linear app, not through anyone's personal account. To trigger a run, a person has to be a member of your Sinatra workspace and have a Linear identity Sinatra can match: their Linear email matches a verified email on exactly one Sinatra account (the address they sign in with by email link, or a verified email on their GitHub account), or they link their Linear account once from the dashboard.
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.