Why CR Cab exists
The problem
Code review coordination is a quiet source of friction on most teams. PRs sit waiting while engineers aren't sure who's available. Messages go out in Slack asking for reviewers. People get interrupted at bad times, or the same few people end up doing most of the reviews.
None of this is visible in sprint metrics, but it adds up: context switches, stalled PRs, uneven review load, and a vague sense that the process could be smoother.
What CR Cab does
CR Cab connects Slack and GitHub to handle reviewer assignment. Engineers declare their availability with a Slack command. When a PR opens, a GitHub Action assigns someone who's available at that priority level.
That's it. No dashboards to check, no new tools to learn, no workflow changes beyond typing a command when your availability changes.
How it works
Set availability
/cr_p1 in Slack means you're available for normal reviews.
Open a PR
The default priority (P1) is used automatically. Most PRs don't need changes—selecting a priority is optional.
Reviewer assigned
GitHub Action picks an available reviewer. No hunting, no waiting.
For teams and leads
- -Less ambiguity: Everyone knows who's reviewing what and when they're available.
- -Fewer interruptions: Engineers control when they're pulled into reviews.
- -More predictable flow: PRs get assigned consistently without manual coordination.
- -No new process: Works with your existing GitHub and Slack setup.
Priority levels
A default priority (P1) is applied automatically, and most PRs use it without changes. Selecting a different priority is optional—typically only needed for urgent fixes (P0) or low-priority/experimental work (P2). CR Cab matches reviewers to the priority they've opted into.