Code Reviewv1.1.0featured

Review a diff, branch or pull request for correctness bugs, security issues and maintainability problems, and report prioritised findings with file and line references. Use when the user asks to review code, check a PR, look for bugs before merging, or asks "what could break".

Author: Velonx
License: MIT
Updated: Sep 25, 2026

code-review development git quality

View on GitHubInstall

Overview

A focused review procedure that finds problems that matter — bugs, security holes, data loss, broken contracts — before style nits, and explains each finding so the author can act on it.

When to Use

"Review this PR / diff / branch", "anything wrong with this?", "is this safe to merge?"
Before a release, after a large refactor, or when onboarding to unfamiliar code.

Installation

coming soonVelonx CLI:velonx install code-review

Get the skill folder
git clone --depth 1 https://github.com/velonx/agent-skills.git
The skill is agent-skills/skills/code-review/. Or open it on GitHub and download the files.
Give SKILL.md to your agent as instructions
Add it to the system prompt, custom instructions or rules file your agent reads. Keep the rest of the folder next to it if the skill refers to examples or scripts.
Ask for the task in your own words
The agent follows the skill when your request matches it. You can also name it: “use code-review”.

Get the skill folder
git clone --depth 1 https://github.com/velonx/agent-skills.git
The skill is agent-skills/skills/code-review/. Or open it on GitHub and download the files.
Claude Code: copy it into a skills folder
cp -R agent-skills/skills/code-review ~/.claude/skills/
Use .claude/skills/ inside a project instead to share it with your team through git.
Claude apps: upload it
Zip the folder and upload it under Settings → Capabilities → Skills.
Ask for the task in your own words
The agent follows the skill when your request matches it. You can also name it: “use code-review”.

Get the skill folder
git clone --depth 1 https://github.com/velonx/agent-skills.git
The skill is agent-skills/skills/code-review/. Or open it on GitHub and download the files.
ChatGPT: add it to a GPT or project
Paste SKILL.md into the instructions, and upload files from the folder as knowledge if the skill uses them.
API: send it as instructions
Use SKILL.md as the system / developer message, or as agent instructions in your SDK.
Ask for the task in your own words
The agent follows the skill when your request matches it. You can also name it: “use code-review”.

Get the skill folder
git clone --depth 1 https://github.com/velonx/agent-skills.git
The skill is agent-skills/skills/code-review/. Or open it on GitHub and download the files.
Gemini app: create a Gem
Paste SKILL.md into the Gem’s instructions.
Gemini CLI or API
Add the contents to your project’s GEMINI.md, or pass it as the system_instruction in the API.
Ask for the task in your own words
The agent follows the skill when your request matches it. You can also name it: “use code-review”.

Get the skill folder
git clone --depth 1 https://github.com/velonx/agent-skills.git
The skill is agent-skills/skills/code-review/. Or open it on GitHub and download the files.
Add it as a project rule
Create .cursor/rules/code-review.mdc and paste the body of SKILL.md. Use the skill’s description as the rule description so the agent applies it when relevant.
Keep the folder in your repo
Only needed if the skill refers to examples or scripts.
Ask for the task in your own words
The agent follows the skill when your request matches it. You can also name it: “use code-review”.

Agents move these settings between versions — if a path doesn’t match, check your agent’s docs.

Usage

Get the change. For a branch: git diff <base>...HEAD. For a PR: fetch the diff. Note which files changed and why (PR description, commit messages).
Understand intent before judging: what is this change supposed to do? If unclear, say so — that is itself a finding.
Read the surrounding code, not just the diff: callers of changed functions, tests, config. Most real bugs are in how new code meets old code.
Check, in priority order:
1. Correctness — logic errors, off-by-one, null/undefined, wrong conditions, race conditions, error paths.
2. Security — injection, missing auth checks, secrets in code, unsafe deserialisation, path traversal.
3. Data safety — migrations, destructive operations, backwards compatibility.
4. Contracts — changed function signatures, API responses, config keys; are all callers updated?
5. Tests — do tests cover the new behaviour and the failure cases?
6. Maintainability — duplication, needless complexity, naming. Keep these brief.
Report each finding as: [severity] path/to/file.ext:line — what is wrong → concrete scenario that breaks → suggested fix Severity: blocker, major, minor, nit.
Lead with a one-line verdict: ready to merge, merge after fixes, or needs rework.
Don't pad: if there are no real issues, say so.