Get started
Your first review
With a repository enabled, the next pull request opened in it gets reviewed. Here is what arrives, and how to read it.
Anyone who opens pull requests sees this. Your existing access to the repository is all it takes.
#Open a pull request
Open one as you normally would, or push to a pull request that is already open. inline picks it up within a minute or two.
A draft waits until you mark it ready. That way inline reads the change once you think it is worth reading, rather than at every step on the way there.
#What arrives on the pull request
inline posts a summary comment describing the change as a whole, and a separate comment on each line worth commenting on. Each of those line comments is a finding, and each one says what it found and why it matters.
Findings arrive as a normal GitHub review, so you reply to them, resolve them, and react to them exactly as you would a colleague's.
inline#482
Cache review results per head SHA · by rojitha · typescript · 2 Sep
Cost
$•.••
Input tokens
184,220
Cached reads
151,008
Output tokens
6,412
Duration
1m 52s
Summary
Caches the review payload against the head SHA. The invalidation path misses force-pushes that keep the same tree.
A force-push that rewrites history without changing the tree reuses the cached review, so the new commit is never read.
bug · confidence 0.82The cache key omits the severity threshold, so lowering it does not produce a fresh review.
bug · confidence 0.74Suppressed by validation gate (2)
#When nothing arrives
When a review finds nothing worth raising, it posts no comments. inline still records the review, so you can open it in Reviews in the portal and see the verdict it reached.
Small changes often come back with a Trivial verdict, which means triage decided a deeper read would add nothing. See How a review works for what leads to each verdict.
#Reply to it
You can talk to inline in the pull request by mentioning it in a comment. Three worth knowing on day one:
| Comment | What inline does |
|---|---|
| @inline review | Reviews the latest changes again. |
| @inline full review | Reads the whole pull request from scratch. |
| @inline why is this a race condition? | Answers your question, reading the code to do it. |
@inline help lists the rest. See Talking to inline on a pull request for the full set.
#When you disagree with a finding
Resolve the thread and carry on. inline records that outcome, and a pattern of the same finding being dismissed becomes a proposed rule for an admin to approve, so the same point stops coming up. See Learnings.
#Once you have seen a few
After a handful of pull requests you will have a sense of whether inline is saying too much or too little. Review config is where you raise or lower the severity threshold, and The merge gate is where you decide whether findings can hold a merge.