Repo Sets

A repo set is a named group of GitHub repositories that Ryven treats as a single triggering unit. You mention @ryven #set:<name> <instruction> in Slack, and Ryven clones every repo in the set together, runs a single agent session across all of them, and opens one pull request per repo that actually changed.

The model is: one task, one agent run, one pull request per changed repo. The whole conversation stays in a single Slack thread.

When to use it

Repo sets exist for the multi-service change case. Classic example: a microservices architecture where api, worker, and shared all need to move together when you bump a shared dependency or change an internal contract. Without a repo set you'd file three separate tasks and hand-copy instructions across threads. With a repo set the agent sees the whole group at once and reasons across boundaries.

Good fits:

• Bumping a shared library and updating every caller
• Renaming an internal API and chasing the rename through consumers
• Splitting or merging services where the change crosses repo boundaries
• Coordinated feature work that touches frontend + backend together

Not a fit:

• Routine single-repo work (just @ryven the repo directly)
• Large fan-outs across 10+ repos — repo sets are hard-capped at 8
• Cross-organization work — all repos must be in the same GitHub App installation

Creating a repo set

Open Settings > GitHub in the dashboard. Repo sets live inside the GitHub card, below the installed-repositories list.

1. Click New repo set
2. Pick a short name — lowercase letters, digits, hyphens, and underscores, up to 40 characters. This becomes the #set:<name> trigger you'll use in Slack.
3. Select up to 8 repositories from the list. Only repos your workspace has connected through GitHub show up here.
4. Save.

Limits

• Max 8 repos per set. This keeps each run fast and focused — if you need to touch more than 8 repos at once, that's usually a sign to split the change.
• All repos must be in the same GitHub organization / installation. Cross-org sets aren't supported.
• No nested sets — a set can't reference another set.
• No duplicates — each repo can appear in a set at most once.

Triggering a task

In any Slack channel where @ryven is installed:

@ryven #set:core-stack bump shared logger to v2 and update all callers

Ryven picks up #set:core-stack and starts a multi-repo task against the set's members. You'll see one Slack thread with status updates for the whole run.

@ryven what lives in #set:core-stack?

Repo sets are a Slack-only trigger. GitHub, Jira, and Linear triggers (issues, PR comments, tickets) are single-repo by nature — if you want a set-wide change from one of those surfaces, write a Slack message instead.

How the run works

1. Parallel clone. Every repo in the set is cloned into the same sandbox at the same time.
2. Per-repo setup. Each repo's ryven.json setup commands run inside that repo, with its own timeout.
3. Merged context. The systemPrompt from each repo's ryven.json is combined (with clear headers marking which repo each instruction came from) and passed to the agent. Secrets listed in each repo's config are all injected into the sandbox.
4. One agent run. Ryven runs a single agent session that can see and edit every repo in the set, so it can reason across boundaries.
5. One PR per changed repo. Every repo that actually changed gets its own pull request. Repos with no changes are skipped.

Your Slack thread gets one aggregated summary:

✅ acme/api — PR #123
✅ acme/worker — PR #45
⏭ acme/shared — no changes

CI fixes across the set

When CI fails on one of the pull requests, Ryven's fix loop pulls every repo in the set back down, tells the agent exactly which repo's CI broke, and lets it make edits across the whole group — since the fix might need a change in a sibling repo. Fixes are pushed as new commits on each affected branch.

Ryven tries up to three CI fixes per task. After that the pull requests are left as drafts for you to take over.

Partial success

Sometimes some repos in a set end up with a PR and others don't — for example, if branch protection blocks a push on one repo but not another. When this happens Ryven marks the task as completed with errors in the dashboard. The PRs that did open are live and their CI is still watched; the repos that errored out are listed in the task detail so you can follow up by hand.

Managing existing sets

In Settings > GitHub you can:

• Filter — when you have 4+ sets, a search input lets you filter by set name or member repo name
• Duplicate — clone an existing set as a starting point for a new one
• Edit — rename or change members
• Delete — removes the set. Tasks that referenced it keep their history; the #set:<name> trigger just stops working.

Quick reference

Related

• Slack — full Slack trigger syntax
• Repository Configuration — how ryven.json works in each member repo