ILSpy/.github/CODE_REVIEW.md

Code review

How to review a pull request, a branch, or a working-tree diff in this repository. Written for both human and agent reviewers; the agent-specific rules are called out where they differ.

CLAUDE.md carries the two rules that have to hold before you have even decided you are reviewing. Everything below applies once you are.

Scope

A PR review and exploratory testing are different jobs. A review is scoped to the feature the PR implements, and reports only genuine bugs the diff caused.

Exploratory testing is encouraged, including on a PR branch — corpus sweeps, nugetfuzz, decompdiff, round-tripping real-world assemblies, probing adjacent language shapes. That is how real bugs get found. But its results never go into the review verbatim: a sweep measures the whole decompiler, not the diff, so most of what it surfaces is pre-existing, unrelated, or a known limitation. Triage first — what the diff caused may become a review comment, everything else becomes an issue.

What earns a comment

• Output that is wrong — it doesn't compile, changes semantics, crashes, or trips a Debug.Assert. A failing assert counts: it names a violated invariant, Debug is what the test suite and every contributor runs, and in Release the same violation just proceeds silently into wrong output.
• Not consequences of a feature the decompiler doesn't implement — that is a limitation, not a defect. Ask whether the finding survives if the gap stays open forever.
• Not pre-existing behaviour the change merely makes visible. That gets its own issue.
• Readability, naming, duplication and performance are fair topics, but only where the magnitude is material. Judge them against what the surrounding code already does, and say what you compared against: a few hundred closure allocations mean nothing beside the millions the transform pipeline already makes, while the same finding on a hot path is worth raising. A number with no baseline is not a finding.
• Coverage gaps in the PR's own feature are in scope, and sweeps are how you find them. Name the uncovered case and the input that reaches it — the PR is the right moment to add the fixture. A bare "this branch is untested" doesn't qualify, and a gap in code the PR didn't touch is an issue.

Evidence

• Build both outputs before calling anything a regression. "This used to work" is a guess until the baseline has actually been compiled or run. Decompiler output is code, so that check is cheap — do it rather than reasoning about it from the diff.
• Every comment carries a minimal repro, what both builds actually printed, and the compiler's diagnostic when the claim is that something no longer compiles. Never what you reason it would print.
• Reproduce what you inherited — sub-agent results, tool summaries, your own earlier conclusions are leads, not evidence.
• Follow each mechanism to its consequence. "This loop starts at 1" is not a finding until you show what breaks. Describing a mechanism correctly and never checking its effect is the most common way an automated review wastes the author's time.
• Be honest about severity. No failing case means the finding is latent, and the comment says so.

Posting

• One finding per comment, and prefer three solid comments to twelve. A recall-maximising sweep is a search stage, not an output format — the filtering is the work. Bundling a verified claim with an unverified one loses you both.
• The author's expertise sets your prior. If they maintain or designed the area, assume their pushback is right: withdraw or rewrite rather than compose a defence. Take the correction at the scope they gave it, though: rejecting specific findings is not a ruling that the topic they were about is off limits.
• Withdraw for a stated reason, not for a quiet life. Cut a finding because it fails the bar, because the baseline disproved it, or because the author showed it was wrong — never because they were sharp about a different comment. A finding nobody has challenged, that still meets the bar, stays. Pre-emptively clearing unopposed comments to shrink your footprint reads as tidying and is really just losing the review.
• Retract by editing; delete only a thread nobody has answered. Deleting a comment that has replies orphans them — GitHub drops their in_reply_to and promotes them to standalone comments, so the other person is left arguing with nothing, and their words look worse than the comment you were removing. Edit yours into a short correction instead. Either way update the review summary so it doesn't advertise findings that no longer exist, and name what was wrong once, without an apology paragraph.