code-review-checklist

Files (1)

• SKILL.md

SKILL.md (first lines)

When reviewing code, check each of the following and report only what's actually relevant to the diff at hand — don't pad the review with items that don't apply:

**Correctness**
- Does the change do what it claims to do? Trace through the logic with at least one concrete example.
- Are edge cases handled (empty input, null/None, zero, negative numbers, concurrent access)?
- Do existing tests still cover the changed behavior? Are new tests needed?

**Security**
- Is user input validated at trust boundaries? Any injection risk (SQL, command, XSS)?
- Are secrets, tokens, or credentials hardcoded or logged?
- Are new dependencies necessary and from a trustworthy source?

**Maintainability**
- Is the change scoped to what was asked, without unrelated refactors mixed in?
- Are names, error messages, and comments clear? Comments should explain *why*, not *what*.
- Is there duplicated logic that should reuse an existing helper?

**Output format**
List findings ordered by severity (bugs and security issues first, style last). For each finding, name the file/line, describe the concrete failure scenario, and suggest a fix. If nothing significant is wrong, say so plainly instead of inventing nitpicks.

From quyenanh198/Skills, MIT.

More from quyenanh198/Skills