Code Review Risk Labels
Every PR gets the cheap single-pass SDK review automatically. On top of that, CI tags each PR with a risk:low / risk:moderate / risk:high label so you know when it's worth opting into a deeper review yourself by running /code-review ultra <PR#> locally (each Claude.ai account gets 3 free runs/month). CI never launches the deep review — the label is a signal, the decision is yours.
.github/code-review-heuristic.yml; the logic is in .github/scripts/classify-risk.ts. Numbers on this page are illustrative — when in doubt, read the YAML, not this doc. The rule
Two independent conditions, evaluated over the PR diff:
cond_path— a modified source file falls under a high-risk path (auth, ramps, playbook draft service, data fields, the workflow/playbook UI, portal security surfaces, …).cond_size— the number of modified source files exceeds the configured threshold.
The label is the XOR of the two:
cond_path | cond_size | Label |
|---|---|---|
| ✗ | ✗ | risk:low |
| ✓ | ✗ | risk:moderate |
| ✗ | ✓ | risk:moderate |
| ✓ | ✓ | risk:high |
Neither → low. Exactly one → moderate. Both → high.
"Modified", not "changed" — why additions don't count
Both conditions count modified source files only — files whose GitHub status is anything other than added (modified, removed, renamed, changed, copied). Brand-new files are excluded from both checks.
The reasoning: a new file has no blast radius on existing call sites by definition. A feature that adds 80 brand-new files is safe in a way that a 20-file refactor of existing code is not — even though the refactor is "smaller." If a new file actually matters, it's used, and that use shows up as a modification to an existing caller (a new import line) — which is what trips the conditions. An orphan new file that nothing reaches yet is correctly low-risk.
Tests and non-code (docs, config, lockfiles) never count either, and a test-only edit to a high-risk path does not trip cond_path — the reviewable production logic isn't changing.
Try it
* Illustrative threshold for this widget only. The live value is source_file_modified_threshold in code-review-heuristic.yml.
Worked examples
Read these as the rule applied to diff shapes — the ✓/✗ columns are what matters, not exact counts.
| Diff shape | cond_path | cond_size | Label |
|---|---|---|---|
| New feature — all brand-new files (even 80 of them), anywhere | ✗ | ✗ | risk:low |
| New files added under a risky dir, no existing file modified | ✗ | ✗ | risk:low |
| A few-line edit to a high-risk file (e.g. an authz check) | ✓ | ✗ | risk:moderate |
| Large refactor of existing code, no high-risk path touched | ✗ | ✓ | risk:moderate |
| Large refactor that modifies a high-risk file | ✓ | ✓ | risk:high |
| Pure rename of an existing module (no content change) | ✓ if under a risky path, else ✗ | counts as modified | risk:moderate+ |
| Docs/config-only PR, or test-only edits | ✗ | ✗ | risk:low |
A rename counts as a modification (it can break importers), so renames are never free — they push toward at least
risk:moderate.
What to do with the label
| Label | Suggested action |
|---|---|
risk:low | Nothing — the automated SDK review is enough. |
risk:moderate | Consider running /code-review ultra <PR#> locally for a deeper pass, especially if you touched the risky area's behavior. |
risk:high | Strongly worth /code-review ultra <PR#> before merge — this PR both modifies a risky surface and is large. |
The separate bot-approved label means the automated review's verdict was LGTM. It is the bot's read, not a human approval — a human review is still required to merge.
Where this lives
- Heuristic config (paths + threshold):
.github/code-review-heuristic.yml - Classifier:
.github/scripts/classify-risk.ts - Workflow + label application:
.github/workflows/code-review.yml,.github/actions/code-review/action.yml - Review rubric (what the SDK review flags):
REVIEW.md