Channel routing

Connected repositories

The repos Angada can see mirror your GitHub App installation — nothing is curated inside Angada itself. If you gave the App access to a repo, it shows up as connected; if you didn't, it won't appear no matter what you do in Angada's settings.

To add or remove a repo, change the GitHub App's repository access from GitHub's side (your installation settings), then let Angada re-sync. See Why don't I see a repo in Angada? if a repo you expect isn't showing up.

The default channel

Any connected repo without an explicit route posts to your Workspace's default channel. This is what lets a new connection start posting immediately, with zero routing setup — you only need to route a repo if you want it somewhere other than the default.

Route a repo to a channel

Routing is per repo — it doesn't change GitHub access, only where that repo's Slack messages land. A repo can be routed to more than one channel; each routed channel gets its own copy of that repo's living PR cards and digests. A single repo can also post to its custom routes and the default channel at once.

Steps

1. Open Routing (/repos). Each repo row shows its current channel as a pill — an unrouted repo shows the default channel, marked as default.
2. On the repo you want to change, use the row's add-channel control to open the channel picker, search for the channel, and select it. The repo now posts to that channel.
3. To route several repos at once, select them with the checkboxes, then use the bulk action bar's Route action — choose a channel and whether to add it alongside existing routes or replace them.

To remove a custom route, use the pill's remove action on that repo's row; it falls back to the default channel automatically. Changing the Workspace's default channel itself (rather than one repo's route) is a separate action in Workspace settings.

Delivery filters per route

Each route can be tuned beyond just "which channel":

• Human-only — inherit the Workspace behavior, or override it for this route.
• Bots — whether pull requests authored by bots are delivered on this route.
• PR comments — whether individual review comments post to the route's threads.
• Author denylist — specific authors whose pull requests are never delivered on this route.

This makes a firehose channel and a leadership channel coexist: the firehose gets everything, leadership gets only what matters.