code-review-general

Stars8

Forks3

UpdatedApril 1, 2026 at 23:54

General code review process: priority ordering, what to block on, how to give actionable feedback

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

ucdavis

ucdavis/ai-skills-registry

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	code-review-general
description	General code review process: priority ordering, what to block on, how to give actionable feedback

Code Review — General

Review Priority Order

Correctness — does it do what it should? Are edge cases handled?
Security — does it introduce vulnerabilities? (See security skill for checklist.)
Performance — N+1 queries, unnecessary allocations in hot paths, missing indexes.
Readability — will the next engineer understand this without context?
Style — does it match project conventions? (Never block on style alone.)

Red Flags (always block)

Hardcoded secrets, API keys, or credentials.
Missing input validation at API/service boundaries.
Unhandled error paths that leave state corrupted.
Race conditions in concurrent code.
Silent exception swallowing (catch (e) {}).

Structural Issues (should fix)

Functions doing more than one thing.
Deep nesting — suggest early returns / guard clauses.
Duplicated logic that should be extracted.
Magic numbers or strings without named constants.

Suggestions (non-blocking)

Better variable/function names.
Simpler implementations.
Additional test cases for uncovered paths.

Tone

Quote the specific line. Explain the problem. Offer a concrete alternative.
Distinguish: "must fix", "should fix", "consider".
Approve with comments for minor issues — block only for correctness, security, or missing tests.
Separate your opinion from objective issues.

More from this repository

same repository

architecture-general

ucdavis/ai-skills-registry

Architecture decisions: layering, design patterns, microservices trade-offs, and domain-driven design

2026-04-018

architecture-python

ucdavis/ai-skills-registry

Python architecture: PEP-8, type hints, clean layering, dependency injection, and testing strategy

2026-04-018

data-science-python

ucdavis/ai-skills-registry

Python data science: notebook structure, data validation, reproducibility, and model documentation

2026-04-018

git-workflow-general

ucdavis/ai-skills-registry

Git workflow: branch naming, conventional commits, PR conventions, and merge strategies

2026-04-018

refactoring-typescript

ucdavis/ai-skills-registry

TypeScript refactoring: SOLID principles, DRY, type safety improvements, and eliminating code smells

2026-04-018

security-general

ucdavis/ai-skills-registry

Security checklist: OWASP top 10, secret scanning, input validation, and auth patterns

2026-04-018

name	code-review-general
description	General code review process: priority ordering, what to block on, how to give actionable feedback

Code Review — General

Review Priority Order

Correctness — does it do what it should? Are edge cases handled?
Security — does it introduce vulnerabilities? (See security skill for checklist.)
Performance — N+1 queries, unnecessary allocations in hot paths, missing indexes.
Readability — will the next engineer understand this without context?
Style — does it match project conventions? (Never block on style alone.)

Red Flags (always block)

Hardcoded secrets, API keys, or credentials.
Missing input validation at API/service boundaries.
Unhandled error paths that leave state corrupted.
Race conditions in concurrent code.
Silent exception swallowing (catch (e) {}).

Structural Issues (should fix)

Functions doing more than one thing.
Deep nesting — suggest early returns / guard clauses.
Duplicated logic that should be extracted.
Magic numbers or strings without named constants.

Suggestions (non-blocking)

Better variable/function names.
Simpler implementations.
Additional test cases for uncovered paths.

Tone

Quote the specific line. Explain the problem. Offer a concrete alternative.
Distinguish: "must fix", "should fix", "consider".
Approve with comments for minor issues — block only for correctness, security, or missing tests.
Separate your opinion from objective issues.