$ luamere freebie --pr-review-labels
Faster reviews in ten minutes.
On the average team, a change spends more than half of its way to production in review (LinearB 2026). Two labels help: how long a PR takes to review, and a warning when it's too big to review well. Free, copy-paste, no account with us.
// what it does
Two labels on every pull request
- "8 min review": the estimated review time, green under 5 minutes, yellow 5-19, red 20+. Reviewers pick up small ones between tasks instead of letting them wait.
- "large PR: consider splitting": on anything over 400 changed lines, where reviews lose depth (SmartBear study at Cisco).
// how to set it up (GitHub)
Three steps
- Install the free gitStream app by LinearB on your repo and add its workflow file, as their guide shows.
- Save the config below as
.cm/gitstream.cmin the repo. - Open a test PR and check the labels appear. Test on one repo before rolling it out.
# -*- mode: yaml -*-
manifest:
version: 1.0
automations:
estimated_time_to_review:
if:
- true
run:
- action: add-label@v1
args:
label: "{{ calc.etr }} min review"
color: {{ colors.red if (calc.etr >= 20) else ( colors.yellow if (calc.etr >= 5) else colors.green ) }}
flag_large_pr:
if:
- {{ branch.diff.size > 400 }}
run:
- action: add-label@v1
args:
label: "large PR: consider splitting"
color: {{ colors.red }}
calc:
etr: {{ branch | estimatedReviewTime }}
colors:
red: 'b60205'
yellow: 'fbca04'
green: '0e8a16'
Based on the gitStream docs example. gitStream is a LinearB product; we're not affiliated, we just like it.
// then agree on one rule
Labels only help with an agreement
Agree as a team: "every PR gets a first review within one working day", the maximum Google's engineering practices recommend. Check it after two weeks. More numbers on our benchmarks page.
// is review your bottleneck?
Find out with your own data.
A Delivery Health Check measures how long work waits for review, where else it gets stuck, and what to fix first. Free for pilot teams now.
See the free pilot →