Reading a review
Learn what each part of a HeyDeer review means, on GitHub and in HeyDeer.
What HeyDeer posts
HeyDeer posts its findings as a GitHub pull request review, with an inline comment on the lines each finding is about.
The review body starts with the outcome and links earlier concerns that still need attention. It ends with a collapsed About this review section: the review summary, the risk level, Review depth, Trigger source, and View in HeyDeer and Config links.
The body also holds review notes, questions under Needs clarification, and findings that can’t go inline. GitHub accepts inline comments only on lines in the diff, so a finding about other code, such as an unchanged caller the change breaks, appears under Additional findings.
The full report is in The HeyDeer Review check and on the review page in HeyDeer. If a review is too long for one GitHub comment, the full report keeps the rest.
HeyDeer approves a pull request only when Automatic approval is on.
With Post review comments on the pull request off, only the check carries the review. See Publish results.
HeyDeer writes everything it posts in the repository’s Review language.
How a finding is laid out
| Part | What it shows |
|---|---|
| Heading | Severity, category and title, for example 🟠 High (Reliability): Retry loop never stops on a 404. |
| Explanation | What’s wrong and what it causes. |
| Suggested change | An exact edit you can commit, when the comment sits on the lines it replaces. |
| Learn more | Collapsed: why it happens, the suggested fix, a read-only diff of a change that can’t be committed here and the repository check that raised it. |
| Affected code | A link to the lines, when the comment isn’t on them. |
Severity (Critical, High, Medium or Low) is the finding’s impact. It’s separate from confidence, which is how sure HeyDeer is that the finding is real. To post fewer or more findings, change the Feedback scope, which combines the two.
To have HeyDeer make the changes in a separate PR for you to review and merge, use Fix with HeyDeer.
Categories
The category is what the finding harms, separate from its severity. When several fit, HeyDeer picks the first in this table.
| Category | What it harms |
|---|---|
| Security | Someone can do or see what they shouldn’t. |
| Correctness | The code gives a wrong result in normal use. |
| Reliability | The code fails under errors, concurrency, load, retries or partial failure. |
| Performance | The code takes too much time or too many resources. |
| Maintainability | Nothing fails, but the code is harder to change, test or read. |
Review notes
When something limited a review, HeyDeer explains it under Review notes in the review body, in the check summary and on the review page.
| Review note | What to do |
|---|---|
| Some findings were omitted | A review keeps only its highest-priority findings, based on confidence and severity. Fix or decline the findings shown, then request another review. |
| Too many repository checks matched | HeyDeer applies matching checks in file name order and skips the rest. Narrow their file patterns, then request another review. |
| Some repository checks are invalid | HeyDeer skips an invalid check and names it. Fix it, then request another review. |
| Some repository checks could not be completed | Request another review. |
| Some findings or earlier concerns couldn’t be fully assessed | Request another review for a complete result. |
A review with review notes is incomplete, so HeyDeer doesn’t approve it and its check doesn’t report success.
For more help with review notes, see Troubleshooting.
Walkthrough
A review on GitHub has a Walkthrough button next to Fix with HeyDeer. It opens the walkthrough in HeyDeer, with related changes grouped together and important changes highlighted. Each group says what to check and shows the code as it is at the reviewed commit.
Related groups share a tab. A tab whose changes span several parts of the system, such as the browser, a server and a database, opens with a diagram: how those parts connect, or the steps between them in order. Select the diagram to enlarge it.
Groups are marked Must read, Should read or Skim. Changes off the main path, such as tests, docs and repeated edits, are listed under Other with the reason. Generated files the review skipped are listed at the end of Other, and a later review of the same pull request tags the groups that changed since the last review.
The walkthrough explains the change; it is not a list of findings. The review page in HeyDeer opens it with Walkthrough too. Turn it off with Walkthrough in the review rules.
Tick Viewed on a file to fold it away. Once every part of the file is ticked, HeyDeer marks the file viewed on GitHub as well, and GitHub clears that mark when the file changes.
The review in HeyDeer
Every review has a page in HeyDeer. Open it from Reviews, from the check’s Details link, or from View in HeyDeer in the review body.
The review page shows the Trigger source and whether it covered New changes or the Whole PR. It also lists every finding within the feedback scope, and concerns under Declined in discussion.
While a review runs, Review progress shows its stages and what each reviewer is doing. After it ends, the collapsed Review activity panel keeps each stage, how long the review took, and what each reviewer did.
When another feedback scope would keep different findings, you can preview it without changing anything: choose the scope beside Findings, or select Preview under a result without findings. Someone with write access can stop a review with Cancel review; credits already used aren’t returned.