What inline learns
Learnings
A learning is one house rule, in a sentence, that inline applies to future reviews. Teach it a rule your team follows and it stops having to be said in review after review.
Anyone can teach a rule from a pull request. Approving a suggested rule, editing one, pinning it, retiring it or changing where it applies is an admin task.
#What a learning is for
Reach for a learning when your team has a rule inline could not work out for itself: a convention you chose, a mistake you keep making, a decision that has a reason behind it.
Where what you want to give inline is a body of expertise, a compliance standard or a domain's worth of guidance, Skills is where it goes.
#Teaching one
Comment @inline learn on any pull request, followed by the rule. inline stores it and applies it to future reviews of that repository.
@inline learn flag any HMAC comparison that is not constant-time is the shape: specific, checkable, and about this codebase. @inline learn global stores the same rule for every repository in the workspace.
#Managing them
Learnings
House rules inline applies to reviews. Taught with @inline learn, written here, or drafted from how your team responds to findings, then promoted and retired automatically on the thresholds below.
Active rules
6
Suggested
2
Agreement since activation
91%
Reviews carrying rules
84 / 92
The page splits rules into Active, Suggested and Retired. Each row shows the rule, where it applies, how many reviews have carried it, how the team's verdicts on its findings lean, and a one-word health reading. Open a row for its evidence (the findings and pull requests behind it), the reviews that carried it, and its full history.
A rule lives in the workspace or in one repository, and can narrow further to a path glob, a language, or both. A narrowed rule goes into a review only when the pull request changes a file it matches. New rule writes one by hand; it is active immediately.
Pinning an active rule keeps it on no matter what the feedback says. Retiring one stops inline applying it and keeps the record. Deleting one removes it and its history.
#Rules inline learns
When your team keeps dismissing the same kind of finding across several pull requests, inline drafts a rule to stop raising it. When it keeps fixing one, inline drafts a rule to keep raising it. Either lands in Suggested first.
With the automatic lifecycle on, a suggestion becomes active once enough consistent, recent verdicts back it, and an active rule is retired when its findings keep being judged against it or it has not been used in months. Every move is recorded with the numbers behind it, and the thresholds are printed on the page.
A few decisions always stay with a person: a rule that would silence bug or security findings never activates on its own, a rule a person retired or dismissed never comes back by itself, and a pinned rule is never moved. Switch Automatic lifecycle off to make every change a person's decision.
Each review records which rules it carried, listed on the review's page. The Finding outcomes card on The dashboard is where a pattern usually shows up first.
#Writing a rule that works
A rule inline can act on says what to look for in a diff. Compare two:
| Rule | What inline can do with it |
|---|---|
| Money is in cents everywhere, so flag float arithmetic on a currency value. | Check every arithmetic expression on a value it can tell is money. |
| Be careful with the billing code. | Nothing specific. There is no test it can run against a diff. |
Write the rule the way you would say it to someone joining your team, and include the reason where the reason is what makes it checkable.