Workflows
Write the rule once. It runs on every pull request.
When this happens on a pull request, do these things. Label it, request a reviewer, post a comment, send an agent to fix it, or drop it in the merge queue. It watches every pull request in your repositories — including ones you did not open — and it runs with the app closed.
- Triggers on what actually happens: opened, checks failed, review requested, approved, commented, merged
- Narrow it with conditions — this repository, this base branch, this label, this author, drafts or not
- Actions that do real work: labels, reviewers, comments, a skill or prompt run, the merge queue
- Every run is logged, per rule, so you can see what fired and what it did
Free plan: three workflows. The cap counts rules you have defined, not the ones that are enabled.
Workflows
Fires on every PR in the repos this workspace watches
Label & route new PRs
When a PR is opened → label it needs-review and ask @dana to review
Fix red CI on my PRs
When checks fail on a PR I opened → run the fix-ci skill
Queue approved PRs
When a PR is approved and checks pass → add it to the merge queue
Nudge stale draftsOff
When a draft PR goes 7 days without a push → comment on it
The decision you keep making
Every time a pull request touches the migrations directory you add the database reviewer. Every time CI fails on a dependency bump you send an agent at it. Every time something is approved and green you queue it. None of these are decisions any more — they are a rule you are executing by hand because nowhere holds it.
A workflow is that rule, written down once, in the app. No YAML, nothing committed to the repository, and nothing that needs the app to be open.
Workflows
Fires on every PR in the repos this workspace watches
Label & route new PRs
When a PR is opened → label it needs-review and ask @dana to review
Fix red CI on my PRs
When checks fail on a PR I opened → run the fix-ci skill
Queue approved PRs
When a PR is approved and checks pass → add it to the merge queue
Nudge stale draftsOff
When a draft PR goes 7 days without a push → comment on it
It reads the event, not your list
A workflow fires off the GitHub webhook payload, not off Talyn's own list of tracked pull requests. That is a deliberate design choice and it is what makes the feature worth having: a rule applies to every pull request in a repository you have connected, including ones you did not open and ones nobody has looked at yet.
Where the event does not carry a fact — an issue comment payload describes an issue, so it has no base branch — a condition on that fact fails rather than quietly passing. A gate that passes when it cannot see is not a gate.
What a rule can do
The actions are the things you would otherwise do by hand, plus the things only Talyn can do.
- Add labels, request reviewers, set assignees
- Post a comment, with the pull request's own details interpolated
- Add it to My PRs, so it shows up on your dashboard
- Run one of your skills, or a freeform prompt, as a cloud agent task
- Add it to the merge queue
The guards, because automation that loops is expensive
Two of them. Talyn ignores events its own GitHub App produced, so a rule that adds a label does not then fire on the label it just added. And each pull request has a ceiling on how many workflow runs it can trigger in an hour, defaulting to five, with the refusal announced once rather than silently.
A rate-limited action is parked and retried when the limit clears, not lost — and the retry re-runs only the actions that had not already succeeded, so a rule whose comment posted and whose label was gated does not comment twice.
Merging is the queue, deliberately
The merge action adds the pull request to Talyn's merge queue rather than calling merge directly. A direct merge on a gated base branch just fails, and a rule that fails silently once a week is worse than no rule. Going through the queue means the pull request waits properly, gets fixed if it breaks, and lands when it is genuinely ready.
Questions, answered.
Rules you set up once that run on their own: when this happens on a pull request, do these things. Pick the trigger, narrow it with conditions, and pick the actions. They watch every pull request in the repositories you connect, including ones you did not open, and they keep running with the app closed.
No. A workflow lives in Talyn, not in your repository. There is no YAML file, nothing to review, and turning one off does not need a pull request.
Yes, as long as the skill is one the backend can read — committed in the repository or saved to your workspace. Skills that only exist in ~/.claude/skills on your machine are refused when you save the rule, because the server cannot see your disk.
No. The cap counts rules you have defined, not rules that are switched on, because counting only the enabled ones would make the cap a toggle — keep twelve, run three, swap whenever. Deleting a workflow frees the slot.
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
Loops
Prompts on a schedule
Read moreFeature
Merge queue
Fixes it, then lands it
Read moreFeature
Skills
Your playbooks, on any PR
Read moreCompare
Talyn vs Mergify
Mergify is a mature merge queue with rule-based automation and CI insights, priced per contributor. Talyn's queue sends an agent to fix a pull request before it lands rather than ejecting it. Where each one wins.
Read the comparison