# Rules for Reviewing Reviews

This reference document provides guidelines for reviewing and filtering generated code review comments (the "review the review" step). Use these rules to ensure that only high-quality, actionable comments are included in the final output.

## Filtering Guidelines

A comment should be **dropped** if it meets any of the following conditions:
- It is not on a line that was actually changed (lines starting with `+` or `-` in the diff).
- It is merely informational, explaining what the code does.
- It is complimentary (e.g., "Good job", "Nice fix").
- It tells the user to "check", "confirm", "verify", or "ensure" something without pointing to a specific issue.
- It is out of bounds for the line range allowed by the SCM API.

A comment should be **kept** or **modified** if:
- It identifies a real issue or bug.
- Its content can be made more concise or actionable.
- Its severity can be adjusted to better match the guidelines.

## Severity Guidelines (Reminders)

Ensure severity levels are applied consistently:

- **Refactoring hardcoded strings/numbers**: Generally `low` severity.
- **Log messages or enhancements**: Generally `low` severity.
- **Comments in Markdown files**: Usually `medium` or `low` severity.
- **Adding/expanding docstrings**: Usually `low` severity.
- **Suppressing warnings or TODOs**: Usually `low` severity.
- **Typos**: Usually `low` or `medium` severity.
- **Test files**: Comments on tests are usually `low` severity unless they point to a critical gap in coverage.

## Code Suggestion Quality

When reviewing code suggestions within comments, ensure:
- They are accurately anchored to the lines they intend to replace.
- They preserve the indentation and spacing of the original code.
- They are compilable or syntactically correct for the language.
- They are succinct and easy to understand.