Code Review Skill

Review pull request diffs and post inline suggestions with clear rationale. Speeds up code review cycles and helps mentor junior developers effectively.

code-reviewgithubdevelopmentquality

Code Review Skill

TL;DR

The Code Review skill reads a pull request diff, analyzes the changed code, and posts inline comments with specific suggestions — including the rationale for each suggestion. It’s designed to catch common issues (security vulnerabilities, performance anti-patterns, missing error handling) before a human reviewer spends time on them, and to provide educational feedback for junior developers.

This is an intermediate-complexity skill because getting useful output requires configuring it for your language, framework, and team conventions. A generic review that flags every style preference as a “critical issue” creates noise, not value.

What it does

  • Reads the PR diff via the GitHub, GitLab, or Bitbucket API and analyzes only the changed lines — not the entire codebase.
  • Posts inline comments on specific lines with a suggestion, the reason it matters, and (optionally) a corrected code snippet.
  • Categorizes findings by severity: blocking (must fix before merge), suggestion (worth considering), and nitpick (style preference, non-blocking).
  • Checks for common security issues — hardcoded credentials, SQL injection patterns, missing input validation, insecure dependencies — using static analysis heuristics.
  • Evaluates test coverage for the changed code, flagging functions that lack corresponding test additions in the PR.
  • Generates a PR summary comment with an overall assessment, a count of findings by severity, and a recommendation (approve / request changes / needs discussion).

Best for

Async review on small teams: When you don’t have enough engineers for thorough human review on every PR, the skill handles the mechanical checks (style, common bugs, missing tests) so human reviewers can focus on architecture and logic.

Mentoring junior developers: The skill explains why a pattern is problematic, not just that it is. A comment like “This loop creates an O(n²) operation — consider using a Set for O(1) lookup” teaches the developer something, rather than just requesting a change.

Enforcing team conventions: Configure the skill with your team’s specific rules (e.g., “always use async/await instead of .then() chains,” “all API endpoints must have rate limiting”) and it will flag violations consistently, without the inconsistency of human reviewers applying rules differently.

Pre-review triage: Run the skill before assigning a human reviewer. If the skill finds blocking issues, the author fixes them first — saving the human reviewer from reviewing code that isn’t ready.

How to use (example)

Scenario: Reviewing a Python FastAPI endpoint PR

A junior developer has opened a PR adding a new /users/{id}/export endpoint. You want the skill to review it before you look at it yourself.

Configuration:

language: "python"
framework: "fastapi"
review_focus:
  - security          # Input validation, auth checks, SQL injection
  - error_handling    # Missing try/except, unhandled edge cases
  - performance       # N+1 queries, missing pagination
  - test_coverage     # Are new functions tested?
severity_threshold: "suggestion"   # Post all findings, not just blocking
post_inline_comments: true
post_summary_comment: true

Example inline comment posted by the skill:

Line 47 — user_id = request.path_params["id"]

🔴 Blocking: Missing input validation

user_id is used directly in a database query on line 52 without type validation. If a non-integer value is passed (e.g., "../admin"), this could cause an unhandled exception or, depending on your ORM, a SQL injection vulnerability.

Suggested fix:

user_id = int(request.path_params["id"])  # Raises ValueError if not an integer

Or use FastAPI’s path parameter typing: async def export_user(user_id: int):

Example PR summary comment:

## Code Review Summary

**Recommendation:** Request Changes

**Findings:**
- 🔴 2 blocking issues (input validation, missing auth check)
- 🟡 3 suggestions (error handling, missing pagination, N+1 query)
- ⚪ 1 nitpick (variable naming)

**Test coverage:** New endpoint has no corresponding test. Please add at least one happy-path and one error-case test.

Human review recommended after blocking issues are resolved.

Common variations:

  • Set severity_threshold: "blocking" to only post comments on issues that must be fixed, reducing noise on large PRs.
  • Add ignore_files: ["*.md", "*.lock"] to skip documentation and dependency lock files.
  • Combine with issue triage to automatically create follow-up issues for suggestions that aren’t addressed in the current PR.

Permissions & Risks

Required permissions: Repo API (read PR diff, write comments)
Risk level: Medium

False positive suggestions are the primary quality risk. The skill may flag valid code as problematic because it lacks the full context of your codebase, your team’s conventions, or the business logic behind a decision. A comment that says “this looks like a security issue” when it isn’t erodes trust in the tool quickly.

IP and proprietary code concerns: The PR diff is sent to the AI model for analysis. If your codebase contains trade secrets, proprietary algorithms, or regulated data (e.g., healthcare or financial systems), check your provider’s data processing agreement. Some teams use on-premises or private cloud deployments for this reason.

Language-specific limitations: The skill performs significantly better on widely-used languages (Python, TypeScript, Go, Java) than on niche languages or domain-specific languages. For languages with limited training data, expect more false positives and missed issues.

Recommended guardrails:

  • Configure a severity_threshold — don’t post every nitpick as a comment on production PRs.
  • Add a confidence_threshold setting so the skill only posts comments it’s reasonably confident about.
  • Make it clear in the PR summary that comments are AI-generated and should be evaluated critically.
  • Never configure the skill to auto-approve or auto-merge PRs — always require human sign-off.

Troubleshooting

Skill is posting too many low-value comments
Lower the noise by raising the severity threshold to “suggestion” or “blocking” only. Also check whether your style preferences (formatting, naming) are being flagged as security issues — configure those as “nitpick” category rules.

Comments are posted on the wrong lines after a rebase
The skill is using stale diff line numbers. Ensure the skill fetches the latest diff after each push to the PR branch, not just the initial diff when the PR was opened.

Skill doesn’t understand our framework’s patterns
Add framework-specific context to the skill configuration: “This project uses FastAPI dependency injection for auth — Depends(get_current_user) is the correct auth pattern, not manual token parsing.” Custom context significantly reduces false positives.

GitHub API rate limits being hit on large PRs
Large PRs (500+ changed lines) generate many API calls for inline comments. Batch comments into a single review submission rather than posting each comment individually. Most GitHub API implementations support this via the “create review” endpoint.

Skill misses obvious bugs
The skill analyzes the diff in isolation — it doesn’t have access to the full codebase context. For bugs that only appear when you understand how a function is called elsewhere, human review is still necessary. The skill is a complement to human review, not a replacement.

Alternatives

GitHub Copilot code review — Integrated directly into GitHub’s PR interface. Requires a Copilot Enterprise subscription. Tighter GitHub integration than a standalone skill; less configurable for custom rules or non-GitHub repositories.

CodeRabbit — A dedicated AI code review SaaS with GitHub and GitLab integration. Supports custom review rules, PR summaries, and learning from your team’s feedback over time. Free tier available for open-source projects.

Manual review with a checklist — A structured checklist (security, performance, tests, documentation) reviewed by a human. Zero false positives; requires reviewer discipline and time. The right choice for security-critical code or when the AI skill’s false positive rate is too high for your team’s tolerance.

Links & sources

  • GitHub REST API — Pull Requests: docs.github.com/en/rest/pulls
  • GitLab Merge Request API: docs.gitlab.com/ee/api/merge_requests.html
  • Related guide: Best Skills for Developers

Related Skills

Explore more AI skills in our directory.

Back to Skills