Review uncommitted changes or a specific diff — when asked to "check my code", "review this", "what is wrong with these changes". Not for writing new code.
Scanned 10/3/2026
npx -y skills add ivanvp91/TRCode --skill code-review --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Code Review?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ivanvp91-code-review)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
name: code-review
description: Review uncommitted changes or a specific diff — when asked to "check my code", "review this", "what is wrong with these changes". Not for writing new code.
description_ru: Проверить незакоммиченные изменения или конкретный дифф — когда просят «посмотри мой код», «отревьюй это», «что не так с этими правками». Не для написания нового кода.
triggers: ревью, review, code review, проверь код, посмотри код, что не так с кодом, диф, diff, pull request, пулреквест, замечания
---
# Reviewing changes
## 1. Collect the diff
- `git status --porcelain` — what is touched at all.
- `git diff` for unstaged, `git diff --staged` for staged.
- If this is not a git repository, ask which files to look at. Do not guess.
## 2. Read more than the diff
A diff lies about context. For every changed file, read the whole function rather than the changed lines only: half of the real bugs live in how a new line interacts with an old one.
## 3. What to look for, most important first
1. **Correctness** — broken logic, inverted conditions, off-by-one, unhandled branches.
2. **Edge cases** — empty input, null/undefined, zero length, negative numbers, concurrent calls.
3. **Errors and resources** — swallowed exceptions, unclosed handles, missing timeouts.
4. **Security** — SQL built by concatenation, unescaped input, secrets in code, path traversal.
5. **Consistency** — anything that breaks the conventions this repository already follows.
Style and taste come last, and only when they genuinely hurt readability.
## 4. Verify a finding before reporting it
For each finding, answer yourself: on exactly what input does this break? If you cannot state the scenario, there is no finding — drop it. A false alarm costs more than a missed nit.
## 5. Answer format
For each finding:
- `path:line` — one sentence on what the defect is.
- The concrete failure scenario: what input leads to what outcome.
- The suggested fix, if it is short.
Sort by severity. If you found nothing, say so in one line — do not invent remarks to fill space.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!