code-review

Stars0

Forks0

UpdatedFebruary 24, 2026 at 06:45

Code review process, effective feedback, PR best practices, team working agreements, review automation, AI-augmented review, and review antipatterns. Use when reviewing code, preparing PRs, giving review feedback, setting up review processes, writing review comments, or conducting code reviews during serve phase.

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

smileynet

smileynet/code-spice

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	code-review
description	Code review process, effective feedback, PR best practices, team working agreements, review automation, AI-augmented review, and review antipatterns. Use when reviewing code, preparing PRs, giving review feedback, setting up review processes, writing review comments, or conducting code reviews during serve phase.

Code Review

Review Goals (Priority Order)

Goal	What You're Checking	Time Allocation
Correctness	Does it work? Edge cases, off-by-ones, null handling	40%
Design	Right abstractions? Fits the architecture?	25%
Security	Auth, input validation, data exposure, injection	15%
Maintainability	Readable? Testable? Future-developer-friendly?	15%
Style	Naming, formatting, conventions	5% (automate this)

Effective Comment Templates (Triple-R Pattern)

Component	Purpose	Example
Request	What to change	"Can we rename `item` to something more descriptive?"
Rationale	Why it matters	"`item` is vague and doesn't convey its role in discount calculation."
Result	What good looks like	"Something like `discountEligibleItem` captures the context."

Comment Severity Labels

Label	Meaning	Author Action
blocker	Must fix before merge	Address or discuss
suggestion	Improvement worth considering	Decide and respond
nitpick	Minor style/preference	Optional — take or leave
question	Need to understand intent	Explain the reasoning
praise	Something done well	Acknowledge (builds trust)

Team Working Agreement (TWA) Template

Area	Questions to Answer
Response time	How quickly should reviews start? (e.g., within 4 business hours)
Review depth	What's expected? (checklist-based? architecture-level?)
PR size limits	Maximum lines? When must PRs be split?
Approval policy	How many approvals to merge? Who can approve?
Comment conventions	Which severity labels? Required vs. optional feedback?
Automation baseline	What's automated? (linting, formatting, security scans)
Escalation	What if reviewer and author disagree?
Exceptions	Emergency/hotfix bypass process?

Review Antipatterns

Antipattern	Symptom	Fix
Rubber-stamping	"LGTM" without reading the code	Require specific comment on at least one aspect
Nitpicking	20 comments about spacing, zero about logic	Automate style; focus comments on design
Gatekeeping	One person blocks all merges with personal preferences	TWA defines objective standards; rotate reviewers
Ghost reviewing	Review assigned, no response for days	SLA with escalation; review rotation
Bike-shedding	Lengthy debate on trivial decisions	Time-box discussions; "author decides" for preferences
Drive-by reviewing	Comments without context or follow-up	Require summary; follow up on requested changes
Scope creep	"While you're here, can you also..."	New work gets its own PR and ticket
Approval hoarding	Requiring 4+ approvals "for safety"	1-2 approvals with clear ownership

AI-Augmented Review (2025-2026)

Concern	What AI Catches Well	What Needs Human Judgment
Bugs	Null derefs, off-by-ones, resource leaks	Business logic correctness
Style	Inconsistencies, formatting	Naming quality, abstraction appropriateness
Security	Injection, XSS, auth issues	Threat model fit
Coverage	Missing test coverage	Test quality
Architecture	Duplication across files	Whether the code solves the right problem

AI-generated code requires more review rigor: 1.75x more logic errors than human code, 45% contain security vulnerabilities. Authors must understand and explain every line.

Decision Tables

"What Should I Focus on in This Review?"

Signal	Focus Area
New contributor's PR	Correctness + mentoring
Touches auth/payments/security	Security-first review
Large refactoring	Design + test coverage
Bug fix	Correctness + regression tests
AI-generated code	Everything + extra scrutiny

"Should I Approve This PR?"

Condition	Decision
All blockers addressed, tests pass, design is sound	Approve
Minor nitpicks only	Approve with comments
Design concerns but implementation is correct	Request changes
Missing tests for new behavior	Request changes
Too large to review effectively	Request split

Reviewer Checklist

PR description explains intent clearly
Changes are appropriately scoped (single concern)
Logic handles edge cases and error paths
New behavior has test coverage
No security concerns (auth, injection, data exposure)
Naming and abstractions fit the codebase
Comments use severity labels (blocker/suggestion/nitpick)

More from this repository

same repository

code-antipatterns

smileynet/code-spice

Antipattern catalog with categorized patterns, symptoms, examples, and fixes. Use when reviewing code for quality issues, detecting bad patterns during plan-audit or scope, evaluating whether a pattern is an antipattern or acceptable tradeoff, or fixing existing code smells. Covers surprise, misuse, complexity, and premature antipattern categories with severity classification.

2026-02-240

code-naming

smileynet/code-spice

Naming decisions for variables, functions, classes, constants, and APIs. Use when choosing names, reviewing naming quality, refactoring unclear names, or establishing naming conventions. Covers descriptive naming, naming as documentation, language-specific conventions, and common naming antipatterns.

2026-02-240

code-plan-audit

smileynet/code-spice

Plan quality auditing with completeness scorecard, antipattern risk detection, and readiness checks. Use when auditing implementation plans, evaluating plan completeness, checking error handling strategy, assessing naming and readability pre-checks, reviewing testing strategy, evaluating tradeoff documentation, or running plan-audit on a software project. Covers the 10-point completeness scorecard, code quality pre-checks, antipattern risk assessment, and build-readiness decision.

2026-02-240

code-pruning

smileynet/code-spice

Dead code detection strategies, safe removal processes, dependency pruning, and bloat metrics for systematically reducing codebase dead weight. Use when evaluating codebase health during architecture-audit, performing cleanup during cook, reviewing unused dependencies, removing commented-out code, or measuring code bloat.

2026-02-240

code-quality-foundations

smileynet/code-spice

Code quality pillars, goals, abstraction layers, and tradeoff thinking. Use when evaluating code quality, setting quality goals, choosing abstraction levels, making design tradeoffs, or auditing code against quality pillars. Covers readability, modularity, testability, reusability, and the principle of least astonishment.

2026-02-240

code-readability

smileynet/code-spice

Code readability patterns covering comments, function decomposition, nesting, naming conventions, and code structure. Use when evaluating whether code is easy to understand, deciding when and how to write comments, decomposing functions, reducing nesting depth, improving code structure, or reviewing code for readability. Covers comment strategy, function length, abstraction level mixing, nesting reduction, anonymous function readability, and making bad code visually obvious.

2026-02-240

name	code-review
description	Code review process, effective feedback, PR best practices, team working agreements, review automation, AI-augmented review, and review antipatterns. Use when reviewing code, preparing PRs, giving review feedback, setting up review processes, writing review comments, or conducting code reviews during serve phase.

Code Review

Review Goals (Priority Order)

Goal	What You're Checking	Time Allocation
Correctness	Does it work? Edge cases, off-by-ones, null handling	40%
Design	Right abstractions? Fits the architecture?	25%
Security	Auth, input validation, data exposure, injection	15%
Maintainability	Readable? Testable? Future-developer-friendly?	15%
Style	Naming, formatting, conventions	5% (automate this)

Effective Comment Templates (Triple-R Pattern)

Component	Purpose	Example
Request	What to change	"Can we rename `item` to something more descriptive?"
Rationale	Why it matters	"`item` is vague and doesn't convey its role in discount calculation."
Result	What good looks like	"Something like `discountEligibleItem` captures the context."

Comment Severity Labels

Label	Meaning	Author Action
blocker	Must fix before merge	Address or discuss
suggestion	Improvement worth considering	Decide and respond
nitpick	Minor style/preference	Optional — take or leave
question	Need to understand intent	Explain the reasoning
praise	Something done well	Acknowledge (builds trust)

Team Working Agreement (TWA) Template

Area	Questions to Answer
Response time	How quickly should reviews start? (e.g., within 4 business hours)
Review depth	What's expected? (checklist-based? architecture-level?)
PR size limits	Maximum lines? When must PRs be split?
Approval policy	How many approvals to merge? Who can approve?
Comment conventions	Which severity labels? Required vs. optional feedback?
Automation baseline	What's automated? (linting, formatting, security scans)
Escalation	What if reviewer and author disagree?
Exceptions	Emergency/hotfix bypass process?

Review Antipatterns

Antipattern	Symptom	Fix
Rubber-stamping	"LGTM" without reading the code	Require specific comment on at least one aspect
Nitpicking	20 comments about spacing, zero about logic	Automate style; focus comments on design
Gatekeeping	One person blocks all merges with personal preferences	TWA defines objective standards; rotate reviewers
Ghost reviewing	Review assigned, no response for days	SLA with escalation; review rotation
Bike-shedding	Lengthy debate on trivial decisions	Time-box discussions; "author decides" for preferences
Drive-by reviewing	Comments without context or follow-up	Require summary; follow up on requested changes
Scope creep	"While you're here, can you also..."	New work gets its own PR and ticket
Approval hoarding	Requiring 4+ approvals "for safety"	1-2 approvals with clear ownership

AI-Augmented Review (2025-2026)

Concern	What AI Catches Well	What Needs Human Judgment
Bugs	Null derefs, off-by-ones, resource leaks	Business logic correctness
Style	Inconsistencies, formatting	Naming quality, abstraction appropriateness
Security	Injection, XSS, auth issues	Threat model fit
Coverage	Missing test coverage	Test quality
Architecture	Duplication across files	Whether the code solves the right problem

AI-generated code requires more review rigor: 1.75x more logic errors than human code, 45% contain security vulnerabilities. Authors must understand and explain every line.

Decision Tables

"What Should I Focus on in This Review?"

Signal	Focus Area
New contributor's PR	Correctness + mentoring
Touches auth/payments/security	Security-first review
Large refactoring	Design + test coverage
Bug fix	Correctness + regression tests
AI-generated code	Everything + extra scrutiny

"Should I Approve This PR?"

Condition	Decision
All blockers addressed, tests pass, design is sound	Approve
Minor nitpicks only	Approve with comments
Design concerns but implementation is correct	Request changes
Missing tests for new behavior	Request changes
Too large to review effectively	Request split

Reviewer Checklist

PR description explains intent clearly
Changes are appropriately scoped (single concern)
Logic handles edge cases and error paths
New behavior has test coverage
No security concerns (auth, injection, data exposure)
Naming and abstractions fit the codebase
Comments use severity labels (blocker/suggestion/nitpick)