PRs that review well

Keep each pull request focused

A pull request that does one thing gets findings about that thing. Keep refactors, renames, and file moves apart from behavior changes, where they bury the lines that actually changed.

Describe the intent and link the issue

HeyDeer reads the title and description. State what the change is for, the part you are least sure about, and what you deliberately left out. When the author has write access, a stated trade-off such as “Retries are out of scope; tracked in #412” counts as a decision, like declining a finding.

Link the issue, too. With Read linked issues on, as it is by default, HeyDeer can read it for the requirements the change should meet. See What HeyDeer reads.

Mark generated files

Mark generated code with linguist-generated in .gitattributes, and HeyDeer leaves it out. HeyDeer reads the attribute from the base branch, so land that change in its own pull request first.

Open a draft while you iterate

Automatic reviews skip drafts by default and consider the pull request once you mark it ready for review. For early feedback, comment @heydeer review on the draft. See Review filters.

Push fixes as new commits

Follow-up reviews look at what changed since the last review, which works best when fixes arrive as new commits. Merging in or rebasing onto the target branch is fine. Push related fixes together to use fewer automatic reviews. See Follow-up reviews.

Reply to findings you decline

Reply in the thread with the reason, not just “won’t fix”, or resolve the thread. A decision by someone with write access tells HeyDeer not to raise the problem again. See Reducing noise.