46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# Code Review
|
|
|
|
## Purpose
|
|
|
|
Review code with a bug-finding mindset that prioritizes correctness, regressions, risky assumptions, edge cases, and missing tests over style commentary.
|
|
|
|
## When to use
|
|
|
|
- Reviewing a pull request or patch
|
|
- Auditing a risky change before merge
|
|
- Evaluating whether a change is safe to ship
|
|
- Checking for test and documentation gaps
|
|
|
|
## Inputs to gather
|
|
|
|
- The diff or changed files
|
|
- Nearby code paths and contracts affected by the change
|
|
- Existing tests, especially those intended to cover the modified behavior
|
|
- Context on expected behavior, rollout risk, and compatibility requirements
|
|
|
|
## How to work
|
|
|
|
- Start with correctness, then move to regressions, then test gaps, then maintainability risks.
|
|
- Trace changed code through call sites, error paths, and data flow rather than reading only the edited lines in isolation.
|
|
- Focus comments on issues that materially affect behavior, safety, or maintainability.
|
|
- Be explicit about severity and the concrete consequence of each issue.
|
|
- Keep summary brief after listing the findings.
|
|
|
|
## Output expectations
|
|
|
|
- A prioritized list of findings with clear reasoning
|
|
- Open questions or assumptions that affect confidence
|
|
- Brief summary of overall risk after the findings
|
|
|
|
## Quality checklist
|
|
|
|
- Findings identify real behavior or verification risk, not cosmetic preferences.
|
|
- Severity is proportional to user impact and likelihood.
|
|
- Missing tests are called out where they reduce confidence materially.
|
|
- If no issues are found, residual risk and coverage gaps are still noted.
|
|
|
|
## Handoff notes
|
|
|
|
- Include file references and tight line references when available.
|
|
- Distinguish confirmed issues from lower-confidence concerns.
|