Why Agent Spinnr Exists
The simple itch behind Agent Spinnr: what if a GitHub issue could just... start fixing itself?
The itch
If you live in GitHub Issues, you already know the shape of the problem. Someone files an issue. It's clear enough. The fix is probably small. And yet it sits in the backlog for a week because everyone is heads-down on something else.
Agent Spinnr started from a dumb little question: what if filing the issue was the trigger? Open it, label it, assign it — and a cloud agent quietly picks it up, reads the repo, takes a first pass, and opens a pull request before anyone has had their second coffee.
What it actually does
The whole thing is deliberately small:
- You install the GitHub App on a repo.
- You add your own background-agent API key (Cursor or Claude Code).
- You pick which events should fire an agent — issue opened, assigned, labeled, edited, commented.
- When one of those events happens, the agent launches with the issue as its prompt, pulls in context from comments and edits, and optionally opens a PR as the bot.
That's it. No planning layer, no roadmap co-pilot, no ceremony. Connect a repo, point it at issues, let agents run.
Why bother
Two reasons.
The first is latency. The gap between "this is a known, small problem" and "someone is actually working on it" is where most momentum dies. Collapsing that gap to zero changes how a backlog feels.
The second is honest curiosity. Background agents got good enough, fast enough, that wiring them straight into the issue tracker stopped being a thought experiment. Agent Spinnr is what happens when you actually build the obvious thing instead of just talking about it.
The honest caveat
This is a toy as much as it is a tool — see Agent Spinnr is a toy (and that's the point). It works, it's genuinely useful on the right kind of issue, and it will also cheerfully open a confidently-wrong PR on the wrong kind. That trade-off is the whole fun of it.
Ready to try? Here's how to use it.