Mission control
Every pull request, triaged. No tabs required.
One live list of every pull request you have open, across every repository you connect, with the blocked ones pulled to the front. Diffs, checks and conversation without leaving the app.
- Live status across every repository and workspace you connect
- A Needs-attention filter that puts the blocked ones first
- Diffs, the check breakdown, and the conversation in one view
- Updates arrive over a websocket, so the list is current without a refresh
feat: streaming results in the dashboard
sundial/web#412 · @dana · opened 2h ago
fix: retry the flaky checkout webhook
sundial/api#418 · @theo · opened 5h ago
perf: cache the search index
sundial/web#407 · @dana · opened 6h ago
chore: bump dependencies
sundial/mobile#21 · @priya · opened 1d ago
The problem is not that GitHub is bad. It is that there is one of you and forty pull requests.
GitHub shows you a pull request very well. What it does not do is tell you which of yours needs you right now. The notifications inbox mixes a failing build into the same stream as a thumbs-up reaction. The pull request list sorts by when something was last touched, which is not the same as how much trouble it is in. So the working pattern becomes ten open tabs and a refresh key.
Talyn answers a narrower question: of everything you have open, what is blocked, and what is ready. That is one list, ordered by how much it needs you, and it is the first thing on screen when you open the app.
feat: streaming results in the dashboard
sundial/web#412 · @dana · opened 2h ago
fix: retry the flaky checkout webhook
sundial/api#418 · @theo · opened 5h ago
perf: cache the search index
sundial/web#407 · @dana · opened 6h ago
chore: bump dependencies
sundial/mobile#21 · @priya · opened 1d ago
What Needs attention actually means
The filter is not a guess. A pull request is in the Needs-attention set because something concrete is true of it: a required check is failing, the branch has fallen behind its base, there is a merge conflict, a reviewer has asked for changes, or it has been approved and nothing has merged it. Each of those is a fact Talyn reads from GitHub, not a score it invented.
That matters because a ranked list you do not trust is a list you stop reading. If a pull request is near the top, you can see the reason on the row.
- Required checks failing
- Behind the base branch, or conflicting with it
- Changes requested, and not yet addressed
- Approved and green, and still sitting there
The whole pull request, without the round trip
Opening a row gives you the diff, the full check breakdown with the failing job's output, the review conversation, and the current review state. You can read what broke and decide what to do about it in the same place you noticed it.
From there the actions are the rest of Talyn: send an agent to fix it, run one of your own playbooks against it, ask for a code review, or drop it into the merge queue if it is simply ready.
services/checkout.ts
- await fetch(webhookUrl, payload)
+ await fetchWithRetry(webhookUrl, payload, { tries: 3 })
How it stays current
Talyn is a GitHub App, so the primary signal is webhooks — a push, a check completing, a review landing, all arrive as they happen and go straight to the open app over a websocket. A reconciliation pass runs behind that as a safety net, because a webhook that never arrives is a state that never updates, and a dashboard that is quietly stale is worse than no dashboard.
The practical result: you do not refresh. A check that goes red goes red on your screen.
It runs where you are
There are desktop builds for macOS, Windows and Linux, and a browser app at app.talyn.dev that needs no install. Same account, same workspaces, same queue. The desktop app adds two things a browser cannot do: it reads skills from `~/.claude/skills` on your machine, and it keeps your session in the OS keychain.
Two honest caveats on the downloads. The Windows installer is not yet code-signed, so SmartScreen will warn you on first install until we buy an EV certificate. And the download button offers the Apple-silicon build on a Mac — if you are on an Intel Mac, take the x64 build from the releases page instead.
Questions, answered.
No. It is a GitHub App you install on the repositories you choose, and it works on a personal private repository with no organisation at all. You pick the repositories during onboarding and can change them later.
Your own pull requests are the main list. Review requests — every open pull request where you are a requested reviewer and have not reviewed yet — live on their own page. Workflows act on every pull request in a connected repository, including ones you did not open.
No. It talks to GitHub over the official API with credentials you supply, and the agent runs happen in a sandbox that clones the repository itself and is destroyed when the task ends.
Talyn does this for you.
Mission control for your GitHub pull requests, running on the Claude or ChatGPT subscription you already pay for. Free for three tasks at a time.
Keep reading
Feature
Review requests
Everything waiting on you
Read moreFeature
Fix a PR with an agent
Failing tests, conflicts, review comments
Read moreFeature
Merge queue
Fixes it, then lands it
Read moreCompare
Talyn vs Conductor
Conductor runs several coding agents in parallel workspaces on your Mac. Talyn runs them in the cloud against the pull requests those agents produced. Different halves of the same day.
Read the comparisonCompare
Talyn vs Graphite
Graphite is built around stacked pull requests, with a merge queue and AI review on top. Talyn is built around getting the pull requests you already have to green and merged. They overlap less than the feature lists suggest.
Read the comparisonGuide
Multiple Claude Code PRs
Running several coding agents at once produces pull requests faster than you can land them. Why they go stale in a predictable order, why updating each branch makes it worse, and what to do instead.
Read the guide