Skip to content

docs(review): enforce rule against challenging PR's stated intent #3420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kilo-code-bot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs(review): enforce rule against challenging PR's stated intent #3420

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions REVIEW.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,22 @@
# Code Review Instructions

# ABSOLUTE RULE: RESPECT THE PR'S STATED INTENT

**Never raise an issue about the stated goal, scope, or design decisions of a PR** unless the approach introduces an unsafe condition (data loss, security vulnerability, correctness bug that contradicts the PR's own objectives).

This is the highest-priority rule and overrides all other review guidance.

**What this means in practice:**

- If the PR description explicitly states a trade-off, limitation, or deferred concern — **do not flag it as an issue**. The author is already aware of it.
- If the PR intentionally narrows scope (e.g. "existing rows will need a one-time cleanup") — **do not flag the out-of-scope items**.
- If an approach differs from how you might have solved it but still meets the PR's stated goal safely — **do not flag it**.
- Design decisions, architectural choices, and intentional scope boundaries described in the PR description must be treated as accepted constraints, not open questions.

**The only exception:** If the described approach is objectively unsafe — e.g. it will cause data loss, introduce a security vulnerability, or produce incorrect behaviour contrary to the PR's own stated goals — flag it with a CRITICAL comment explaining the specific unsafe condition.

> **Example of a violation of this rule:** A PR says "Existing old idle pending rows need manual retry or a one-time cleanup if we want to move them." Flagging this as an issue (e.g. "old rows will become invisible after deploy") is incorrect — the author already acknowledged this and it is part of the intentional design. Do not raise it.

# WHAT TO REVIEW

**Flag these (high confidence only):**
Expand Down