An AI agent for GitHub issues
Label the issue. Sinatra opens a branch, writes the code, reviews its own diff as a pull request review, and reacts to your CI. Everything it has to say lands on the issue or the pull request, so review never leaves GitHub.
The label is the trigger
Adding the Sinatra label to an issue is what starts a run. The label is named after the GitHub App, so on the hosted app it is sinatraai, and Sinatra creates it on every repository you enable rather than making you set it up. That step is best effort: if it fails, the label is missing rather than misnamed, and you can add it yourself from repository settings.
That is the only way in. GitHub Apps cannot be issue assignees, so assignment does nothing, and a comment cannot begin a run either. Comments steer a run that already exists. Remove the label, or close the issue, and the run is cancelled. Reopen a still-labelled issue and it starts again.
On pull requests, Sinatra only listens to comments that @-mention it, and only from repository owners and members. A drive-by comment on a public repository cannot put an agent to work in your codebase.
Progress lands in one comment, not fifty
Sinatra keeps a single Agent Updates comment on the issue and edits it as the run proceeds, rather than posting a new comment per step. Subscribers get one notification instead of a running commentary, and the issue stays readable afterwards.
That comment survives the machinery underneath. A long run that has to hand off internally, or one that idles overnight and is revived by your next comment, keeps writing to the same comment instead of starting a fresh one.
Draft, self-review, then ready
The agent opens its pull request as a draft while it is still working. When the code settles, Sinatra reviews its own diff and publishes the result as a native pull request review: one review event carrying a report card, plus inline comments anchored to specific lines for anything it could not safely fix itself. Findings it can fix, it fixes, as a new commit rather than a rewritten history.
Only then is the pull request marked ready for review. If that review is interrupted, by a restart or by you commenting while it runs, the pull request stays a draft on purpose, so a half-finished branch never lands in anyone's review queue. On later iterations Sinatra reviews only what changed since it last looked, and supersedes its own earlier report card instead of stacking a new one on top.
It reacts to your CI
When a check suite completes on a Sinatra pull request, Sinatra reads the result. A failure sends the agent back to fix it, twice by default. You can set that with ci.max_rework in .sinatrarc, anywhere from 0 to 10. When the budget is spent the run stops and waits for a human, because an agent looping on a failure it does not understand is worse than one that admits it is stuck.
Repeat failures for a check suite it has already reworked do not consume more budget, and cancelled or neutral suites are ignored entirely. Sinatra reads check results and never writes them, so this is a one-way integration: your CI configuration is yours.
Review it like a teammate
Submit a review requesting changes and Sinatra picks up your inline comments, reworks the branch and replies in each thread rather than in one summary comment. An approving review deliberately triggers nothing, because an approval is a signal for a human to merge, not an instruction to keep going. You can also @-mention Sinatra in a pull request comment and ask for a specific change without filing a formal review.
Sinatra never merges, and it does not close your issue directly. It writes a closing keyword into the pull request description so GitHub closes the issue when the pull request merges, on your schedule.
Setting it up
It asks for contents and pull requests read and write, issues read and write, and checks read only. Nothing else.
Sinatra provisions the trigger label on each one as you enable it.
Add a test command to .sinatrarc and Sinatra runs it in the sandbox after the agent finishes, re-running the agent to fix failures up to twice.
Something small and real. Watch the Agent Updates comment.
Common questions
How do I trigger Sinatra on a GitHub issue?
Add the Sinatra label to the issue. The label is named after the GitHub App, so on the hosted app it is sinatraai, and Sinatra provisions it on each repository you enable. The label is the only way to start a run. Comments steer a run that already exists, they cannot begin one, and GitHub Apps cannot be assignees so assignment does nothing.
Why does the pull request open as a draft?
Because Sinatra reviews its own diff before asking for your attention. Once that review is posted the pull request is marked ready. If the review is interrupted, by a restart or by you commenting while it runs, the pull request is deliberately left as a draft so nobody is paged for work that isn't finished.
What happens when CI fails on a Sinatra pull request?
Sinatra sees the completed check suite and sends the agent back to fix it, twice by default. The budget is set with ci.max_rework in .sinatrarc and accepts 0 to 10. Once it is spent, the run stops and waits for a human rather than looping. Cancelled and neutral check suites are ignored.
Can I ask Sinatra to change something in code review?
Yes. Submit a review requesting changes and Sinatra reworks the branch and replies in the review threads. An approving review deliberately does nothing. You can also @-mention Sinatra in a comment on the pull request if you want a specific fix without a formal review.
Tracking work in Linear instead? The Linear ticket workflow is triggered by assignment and reports into the agent session. Full configuration reference is in the documentation.