Code review

Skill arozumenko/wikis/.claude/skills/code-review

Review code for correctness, security, performance, and maintainability. Use when the user asks to "review this code", "check my changes", "review PR", "audit", or "what do you think of this approach".From its SKILL.md

Install

npx -y skills add arozumenko/wikis --skill code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.6 KB, as published. Nobody here has run it

Code Review

Systematic code review focused on what matters. Not a style police — a correctness and risk checker.

Review Scope

Determine what to review:

# Review staged changes
git --no-pager diff --cached

# Review working tree changes
git --no-pager diff

# Review a PR
gh pr diff <number>

# Review specific files
# Just read them directly

Review Checklist

Check in this priority order. Stop at each category — don't rush to the next.

1. Correctness

Does it do what it claims?
Are edge cases handled (nulls, empty collections, boundary values)?
Are error paths correct (not swallowed, not over-caught)?
Do conditional branches cover all cases?

2. Security

Input validation at system boundaries (user input, API responses)?
SQL injection, XSS, command injection risks?
Secrets in code or logs?
Permissions and authorization checked?

3. Concurrency & State

Race conditions in shared state?
Proper locking/synchronization?
Async operations awaited correctly?
Resources properly closed/released?

4. Performance

O(n^2) or worse in hot paths?
Unnecessary allocations in loops?
N+1 query patterns?
Missing indexes for new queries?

5. Maintainability

Is the intent clear from reading the code?
Could someone unfamiliar modify this safely?
Are there implicit assumptions that should be explicit?

Output Format

Structure your review as:

## Summary
One sentence: what this change does and whether it looks good.

## Issues
### [Critical/Important/Nit] Title
File: path/to/file.py:42
Description of the issue and why it matters.
Suggested fix (if non-obvious).

## Questions
Things that aren't wrong but need clarification from the author.

Severity levels:

Critical — will break in production, security vulnerability, data loss risk
Important — correctness issue, significant performance problem, missing error handling
Nit — style, naming, minor improvement (limit to 2-3 max, don't pile on)

What NOT to Review

Style preferences already handled by formatters/linters
Adding type hints to code the author didn't change
Suggesting refactors unrelated to the change
Commenting on test structure unless tests are wrong