majiayu000 Review Correctness
Analyze code for bugs and correctness problems. Return structured findings.
Step 1: Determine the Scope
Determine what to review:
- If a specific diff command was provided (e.g.,
git diff --cached,git diff main...HEAD), use that. - If a file list or directory was provided, review those files directly (read the full files, not a diff).
- If neither was provided, default to diffing against the repository's default branch (detect via
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name').
Step 2: Review
- For diff scope: run the diff command to obtain the changes. For file scope: read the specified files.
- For each file, read enough surrounding context to understand the code
- Apply the bug determination criteria and return findings in the output format below
Bug Determination Criteria
Flag an issue only when ALL of these hold:
- It meaningfully impacts the accuracy, performance, security, or maintainability of the code
- The bug is discrete and actionable (not a general codebase issue or combination of multiple issues)
- Fixing it does not demand rigor beyond what exists in the rest of the codebase
- In diff mode: the bug was introduced in the changeset (do not flag pre-existing bugs). In file scope mode: this criterion does not apply
- The author would likely fix the issue if aware of it
- The bug does not rely on unstated assumptions about the codebase or author's intent
- Speculation is insufficient — identify the parts of the code that are provably affected
- The issue is clearly not an intentional change by the original author
Comment Standards
- Be clear about why the issue is a bug
- Communicate severity accurately — do not overstate
- Keep the body to one paragraph maximum
- No code chunks longer than 3 lines. Use markdown inline code or code blocks
- Explicitly communicate the scenarios, environments, or inputs needed for the bug to arise
- Use a matter-of-fact tone, not accusatory or overly positive
- Write so the author can immediately grasp the idea without close reading
- No flattery ("Great job...", "Thanks for...")
Priority Levels
- P0 — Drop everything. Blocking release or operations. Only for universal issues that do not depend on assumptions about inputs
- P1 — Urgent. Should be addressed in the next cycle
- P2 — Normal. To be fixed eventually
- P3 — Low. Nice to have
What to Ignore
- Trivial style unless it obscures meaning or violates documented standards
- In diff mode: pre-existing issues not introduced by this changeset
Output Format
Return findings as a numbered list. For each finding:
### [P<N>] <title (imperative, ≤80 chars)>
**File:** `<file path>` (lines <start>-<end>)
<one paragraph explaining why this is a bug, what scenarios trigger it, and the impact>
After all findings, add:
## Overall Verdict
**Correctness:** <correct | incorrect>
<1-3 sentence explanation>
If there are no qualifying findings, state that the code looks correct and explain briefly.