Review Comments

Treat every comment as permanent maintenance cost. Keep it only when its durable value exceeds that cost.

Prefer code that explains itself. Use comments to preserve information that cannot be expressed clearly in names, types, structure, tests, assertions, or APIs.

Establish scope

1. Inspect repository instructions before reviewing.
2. Default to the current Git changes: staged, unstaged, and untracked source files. If these are empty, inspect the branch diff against the repository's evident base branch.
3. Focus on added or modified lines. Include a nearby existing comment only when changed code makes it inaccurate, misleading, redundant, or necessary to understand the change.
4. Do not sweep untouched legacy code or the whole repository unless explicitly requested.
5. Exclude generated files, vendored sources, lockfiles, snapshots, minified files, and third-party code unless explicitly included.
6. Preserve license headers, attribution, required generated-file warnings, and repository-mandated notices.

If staged and unstaged changes both exist, inspect both unless the user names a narrower surface. State the chosen surface; ask only when choosing incorrectly could change or overwrite work outside the requested scope.

If the user requests review only, report proposed changes without editing. If the user requests cleanup, rewriting, fixing, or implementation, apply the changes.