Tuning reviews
Review config
Review config holds your workspace defaults. Change something here and every repository picks it up, unless that repository has been told otherwise.
Changing these is an admin task. Everyone on the team sees the result, so it is worth knowing what each control does before you move it.
#How a setting reaches a review
Each setting here is the starting point for every repository in your workspace. A repository can override most of them from its own settings, and where it has not, it follows what you set here.
Your instructions and your ignored paths behave differently. They add to whatever a repository sets, so a rule you write here stays in force everywhere and a repository can only ever add to it. See Repository settings.
#How loudly inline speaks
Review configuration
Defaults every repository inherits. Repos can override most settings on their own page or in .inline.yml unless a setting is locked under Enforced policy.
Defaults
Severity threshold
LowMediumHighReviews post as
inline botYour accountMerge gate
Default mode
OffReportBlock highBlock med+Block allCheck fails while high-severity findings are open — resolve the thread or push a fix to clear.
Sandbox tests
AutoOffReportBlockMonthly AI budget
Cap (USD)
No capSeverity threshold is the single most useful control on this page. It sets how serious a finding has to be before inline posts it to the pull request. Anything quieter is still recorded, and admins can read it on the review itself.
| Threshold | What your team sees |
|---|---|
| Low | Everything, including small improvements. Loud, and good while you are learning what inline notices. |
| Medium | The default. Bugs and things worth fixing before merge. |
| High | Only what will bite. Quiet enough that a comment always means something serious. |
If you are unsure, leave it at Medium and read the held-back findings on a few reviews. That tells you what you would gain by widening it. See Findings.
Reviews post as decides whose name is on the comments: the inline bot, or Your account where you connected GitHub personally. See Connect GitHub.
#The merge gate and sandbox tests
Merge gate sets the workspace Default mode, and Sandbox tests decides whether a test result feeds the same check. Both are explained in full on The merge gate.
#The monthly ceiling
Monthly AI budget puts a ceiling on the workspace for a calendar month. Cost and budgets covers what happens as you approach it and what to set it to.
#What runs on every review
Four switches decide how much work each review does beyond reading the code. All four start off, so you turn on what your team wants rather than switching things off.
| Setting | What turning it on does |
|---|---|
| Walkthrough pages | Builds a walkthrough for every review, so reviewers can read the change in the order it was built. |
| Sandbox test runs | Runs your suite before inline posts, so its claims are checked. See Sandbox tests. |
| Static analysis | Folds linter and SAST results into the review, triaged so only what matters is posted. |
| Breaking-change detection | Scans your other repositories for code that would break, and reports it on the pull request. |
#What you tell inline about your team
The bottom of the page is where you give inline standing context, and it is the part most worth spending time on.
| Setting | What it does |
|---|---|
| Workspace instructions | Free text that goes into every review. Write the things you would tell a new reviewer on their first day. |
| Ignored paths | Globs inline skips. Lockfiles, build output and generated code are already skipped, so add what is specific to you. |
| Workspace skills | Expertise attached to every repository. See Skills. |
A good workspace instruction is specific and checkable. "We are a healthcare company, treat any handling of patient data as high severity" changes what inline flags. "Write good code" does not.
Choose Save configuration when you are done. inline confirms with Workspace configuration saved, and the next review of any repository uses what you set.