claudegoodies
Skill

code-review-and-quality

From addyosmani

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

Reviews code changes across correctness, readability, architecture, security, and performance before merge.

Use it when

  • Before merging a PR or any code change
  • After completing a feature implementation
  • Evaluating code written by another agent or model
  • After a bug fix, to review the fix and its regression test

Skip it if

  • No source content on tooling or automation, it's a review checklist not a scanner
  • Security and performance depth deferred to other skills (security-and-hardening, performance-optimization)
  • Requires human/agent judgment calls, not automated pass/fail output

Facts

Repository
addyosmani/agent-skills
Status
Actively maintained
Last commit
Source file
skills/code-review-and-quality/SKILL.md

Source preview

The instructions Claude Code reads when this skill runs.

# Code Review and Quality

## Overview

Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.

**The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.

## When to Use

- Before merging any PR or change
- After completing a feature implementation
- When another agent or model produced code you need to evaluate
- When refactoring existing code
- After any bug fix (review both the fix and the regression test)

## The Five-Axis Review

Every review evaluates code across these dimensions:

### 1. Correctness

Does the code do what it claims to do?

- Does it match the spec or task requirements?
- Are edge cases handled (null, empty, boundary values)?
- Are error paths handled (not just the happy path)?
- Does it pass all tests? Are the tests actually testing the right things?
- Are there off-by-one errors, race conditions, or state inconsistencies?

### 2. Readability & Simplicity

Can another engineer (or agent) understand this code without the author explainin
View full source on GitHub →

Other skills