SKILLS.MD

Code review

Review a diff or PR for correctness and clarity.

When agents use this

Reviews code changes for correctness, edge cases, readability, and security, then reports issues grouped by severity with a merge call. Use when the user shares a diff, a pull request, a commit, or a set of changed files and wants a review, feedback, or a decision on whether it is ready to merge, even if they just paste code and ask what you think.

Code review

Review the diff and report issues grouped by severity. Review only what changed and why; do not rewrite the whole file or relitigate choices outside the diff.

How to review

  1. Read the change against its stated intent before judging it. If the intent is unclear, the first finding is that the change lacks a clear purpose.
  2. Correctness. Trace the actual data flow, not the happy path. Off-by-one, null and undefined, unhandled promise rejections, missing await, race conditions on shared state, and the empty and boundary inputs the author did not test.
  3. Error handling. Every thrown or rejected path either recovers or surfaces a real message. Flag swallowed errors and catch blocks that hide the cause.
  4. Security. Untrusted input reaching a query, shell, or DOM without parameterization or escaping; secrets in source; authz checks missing on a new endpoint or mutation.
  5. Readability. Flag only what a reader would genuinely misread: a name that lies about what it holds, a branch whose condition is inverted from its comment, control flow that needs a comment to follow. Do not flag style a formatter owns.

Gotchas

  • A diff shows added lines, not the call sites you did not touch. A renamed or re-typed export can break a caller outside the diff. Grep for other users before trusting that a change is local.
  • "The tests pass" is not "the change is correct." A test can pass because it asserts the buggy behavior, or because it never exercises the new path. Read what the test actually asserts.
  • A deleted line is a change. Removed validation, a dropped await, or a deleted cleanup is easy to skim past because nothing new is there to read.
  • Match the severity to the failure, not to how easy it is to spot. A silent data-loss path buried in a helper outranks ten naming nits.

Output

Group findings by severity, most severe first. Quote the exact line for each. Use this shape:

Code review: [what was reviewed]

Blocking

  • path:line [what breaks and the input that triggers it]. Fix: [concrete change].

Should-fix

  • path:line [the problem]. Fix: [change].

Nit

  • path:line [the smaller issue]. Fix: [change].

Merge call: [ship / fix blocking first / needs rework], one line of why.