Go review order
Review Flow
Start with the intended product boundary before reading individual functions. Identify the module, package, command, service endpoint, or runtime layer that owns the behavior. Then review the public contract, package design, implementation details, tests, and documentation. Code that is locally tidy can still be wrong when it puts behavior in the wrong module, duplicates a data contract, or hides domain logic inside a presentation layer.
Prefer concrete findings over taste. A good review comment says what behavior becomes harder to prove, maintain, or extend. Avoid asking for abstraction only because a function is long, or for inlining only because a helper is small. The question is whether the current shape makes the next correct change obvious.
Use the focused pages in this guide as the review map. Start with ownership and architecture, then move through API and type design, implementation concerns such as control flow and mutation, failure behavior in errors and CLI diagnostics, and the evidence in tests and evidence. When the finding is meant for an automated reviewer, use the compact names in LLM finding patterns.