# PR Review Standards
+## Review Philosophy
+* Only comment when you have HIGH CONFIDENCE (>80%) that an issue exists
+* Be concise: one sentence per comment when possible
+* Focus on actionable feedback, not observations
+* When reviewing text, only comment on clarity issues if the text is genuinely confusing or could lead to errors.
+
## What to Analyze
Review all code changes for:
- Documentation updates if needed
## PR Title
-
The PR title must be a functional description of the change. It must NOT contain conventional commit prefixes such as `feat:`, `fix:`, `refactor:`, `chore:`, etc. Labels are used to categorize PRs, not the title. Flag as `[PROBLEM]` if the title uses such prefixes.
-## Existing Review Comments
+## CI context
+**Important**: You review PRs immediately, before CI completes. Do not flag issues that CI will catch.
-Ensure any existing review comments on the PR have been addressed before approving.
+### What Our CI Checks (`.github/workflows/test.yml`)
+**Lint checks:**
+* SKIP=no-commit-to-branch pre-commit run --all-files
+* See .pre-commit-config.yaml for the full list of checks
-## Issue Categories
+**Runs test:**
+* pytest --durations 10 --cov-report term-missing --cov=music_assistant --cov-report=xml tests/
+## Skip These (Low Value)
+Do not comment on:
+
+* Style/formatting (pre-commit handles this)
+* Test failures
+* Missing dependencies (ci handles this)
+* Minor naming suggestions
+* Suggestions to add comments
+* Multiple issues in one comment
+* Logging suggestions unless security-related
+
+## Issue Categories
Categorize every issue found as one of:
- `[CRITICAL]` — must be fixed before merging (bugs, security issues, broken functionality)
- `[PROBLEM]` — should be fixed (code quality, bad patterns, missing tests)
- [PROBLEM] Inefficient algorithm in music_assistant/helpers/data_processing.py
- [SUGGESTION] Improve variable naming in music_assistant/helpers/config_validation.py
```
+
+Output Comment Format
+1. State the problem (1 sentence)
+2. Why it matters (1 sentence, if needed)
+3. Suggested fix (snippet or specific action)
+
+Example:
+This could generate a `KeyError` if `"name"` does not exist in the `dict`. Consider using `.get("name")` or adding a check.
--- /dev/null
+# PR Review Standards
+
+## Review Philosophy
+* Only comment when you have HIGH CONFIDENCE (>80%) that an issue exists
+* Be concise: one sentence per comment when possible
+* Focus on actionable feedback, not observations
+* When reviewing text, only comment on clarity issues if the text is genuinely confusing or could lead to errors.
+
+## What to Analyze
+
+Review all code changes for:
+- Code quality and style consistency with the existing codebase
+- Potential bugs or issues
+- Performance implications
+- Security concerns
+- Test coverage
+- Documentation updates if needed
+
+## PR Title
+The PR title must be a functional description of the change. It must NOT contain conventional commit prefixes such as `feat:`, `fix:`, `refactor:`, `chore:`, etc. Labels are used to categorize PRs, not the title. Flag as `[PROBLEM]` if the title uses such prefixes.
+
+## CI context
+**Important**: You review PRs immediately, before CI completes. Do not flag issues that CI will catch.
+
+### What Our CI Checks (`.github/workflows/test.yml`)
+**Lint checks:**
+* SKIP=no-commit-to-branch pre-commit run --all-files
+* See .pre-commit-config.yaml for the full list of checks
+
+**Runs test:**
+* pytest --durations 10 --cov-report term-missing --cov=music_assistant --cov-report=xml tests/
+
+## Skip These (Low Value)
+Do not comment on:
+
+* Style/formatting (pre-commit handles this)
+* Test failures
+* Missing dependencies (ci handles this)
+* Minor naming suggestions
+* Suggestions to add comments
+* Multiple issues in one comment
+* Logging suggestions unless security-related
+
+## Issue Categories
+Categorize every issue found as one of:
+- `[CRITICAL]` — must be fixed before merging (bugs, security issues, broken functionality)
+- `[PROBLEM]` — should be fixed (code quality, bad patterns, missing tests)
+- `[SUGGESTION]` — optional improvement (style, minor refactors, nice-to-haves)
+
+## Output
+- Post inline comments on GitHub for every `[CRITICAL]` and `[PROBLEM]` issue found.
+- Do NOT post `[SUGGESTION]` items to GitHub.
+- Do not list things that are already correct
+
+## Output Comment Format
+1. State the problem (1 sentence)
+2. Why it matters (1 sentence, if needed)
+3. Suggested fix (snippet or specific action)
+
+Example:
+This could generate a `KeyError` if `"name"` does not exist in the `dict`. Consider using `.get("name")` or adding a check.
+
+## When to Stay Silent
+If you’re uncertain whether something is an issue, don’t comment.
+++ /dev/null
----
-applyTo: "**"
-excludeAgent: "code-agent" # Only used by the code review agent in Github
----
-
-# PR Review Standards
-
-## What to Analyze
-
-Review all code changes for:
-- Code quality and style consistency with the existing codebase
-- Potential bugs or issues
-- Performance implications
-- Security concerns
-- Test coverage
-- Documentation updates if needed
-
-## PR Title
-
-The PR title must be a functional description of the change. It must NOT contain conventional commit prefixes such as `feat:`, `fix:`, `refactor:`, `chore:`, etc. Labels are used to categorize PRs, not the title. Flag as `[PROBLEM]` if the title uses such prefixes.
-
-## Existing Review Comments
-
-Ensure any existing review comments on the PR have been addressed before approving.
-
-## Issue Categories
-
-Categorize every issue found as one of:
-- `[CRITICAL]` — must be fixed before merging (bugs, security issues, broken functionality)
-- `[PROBLEM]` — should be fixed (code quality, bad patterns, missing tests)
-
-## Output
-
-- Post inline comments on GitHub for every `[CRITICAL]` and `[PROBLEM]` issue found.
-- Do NOT post `[SUGGESTION]` items to GitHub.
-- Do not list things that are already correct
projects / music-assistant-server.git / commitdiff