code-review-skill: a Claude Code skill for structured code review across 20+ languages

What a Claude Code skill is and how code-review-skill extends it

Claude Code supports a skill system where a Markdown file, placed and registered as a skill, loads into the AI's context when invoked. These files carry structured instructions, review criteria and domain-specific rules that shape how Claude Code approaches a specific task. Code-review-skill is one such file: SKILL.md at the repository root is the skill entry point, and it loads additional language-specific guides from the reference/ directory on demand.

The problem it addresses is consistency in AI-assisted code review. Without structured input, a code review request to an AI produces responses that vary in depth, miss domain-specific concerns and mix blocking defects with stylistic preferences. Code-review-skill replaces that variability with a defined four-phase process, explicit severity categories and per-language review checklists that cover security, performance and common anti-patterns for each ecosystem.

It is squarely for teams that already use Claude Code as part of their development workflow. If Claude Code is not in use, there is no mechanism to apply this skill.

Progressive disclosure loads ~220 lines of core rules, then language guides as needed

Loading 21,000 lines of guidelines into every review session would exhaust a context window before the actual code appears. Code-review-skill avoids that by separating a small core from the language-specific detail. The core SKILL.md is approximately 220 lines. Each language guide in reference/ ranges from around 310 lines (the N+1 queries guide at reference/cross-cutting/n-plus-one-queries.md and the SQL injection prevention guide) up to approximately 1,070 lines for Python and 1,060 lines for Svelte 5.

When a review session starts, only the core loads. Language-specific guides load when the content of the review calls for them, which means a Go review pulls in reference/go.md at around 990 lines rather than loading every guide simultaneously. This is what the README calls progressive disclosure, and it is the architectural decision that makes a 21,000-line skill file practical within the context limits of a single session.

A consequence of this design: a review that spans multiple languages in one session will load multiple guides, and the combined weight of the core plus two or three language files starts to approach the limits of smaller context windows.

Six severity labels rank every finding from blocking to praise

Every finding the skill produces carries one of six severity labels: blocking, important, nit, suggestion, learning and praise. Blocking means the change cannot ship as-is. Important means a defect that should be fixed but is not a hard stop. Nit covers minor style or naming issues. Suggestion offers an alternative approach without requiring a change. Learning identifies something that teaches a concept. Praise names something done well.

That last two categories distinguish the skill from a pure defect-finding process. Including praise and learning in the output is an explicit design choice about how code review affects the person receiving it. Marking a security pattern correctly applied as praise gives a concrete signal about what to repeat, rather than treating correct code as silent approval.

For teams that track code review output in any structured way, these labels make the data more usable. A list of all blocking and important findings across a sprint is a different artifact from a list of all findings, and having that split requires consistent labeling from the start.

Twenty-one language guides and nine cross-cutting topics in reference/

The reference/ directory holds the bulk of the content. Language guides cover frontend frameworks: React 19 with Next.js and TanStack Query v5 at reference/react.md (~870 lines), Vue 3.5 with Composition API at reference/vue.md (~920 lines), Angular 17+ with Signals and Zoneless at reference/angular.md (~790 lines), Svelte 5 with SvelteKit at reference/svelte.md (~1,060 lines) and TypeScript at reference/typescript.md (~1,020 lines).

Backend guides include Django/DRF at reference/django.md (~1,030 lines), Python at reference/python.md (~1,070 lines), Go at reference/go.md (~990 lines), Rust at reference/rust.md (~840 lines), Ruby 3.4+/4.0 with Rails 8.x at reference/ruby.md (~960 lines) and Java 17/21 with Spring Boot 3 at reference/java.md (~410 lines), with a separate Java 8 + Spring Boot 2 guide at reference/java8.md (~580 lines).

Nine cross-cutting guides handle topics that span languages: architecture design review, performance review, universal quality anti-patterns, security review, N+1 queries, error handling principles, async and concurrency patterns, SQL injection prevention and XSS prevention. These live under reference/ and reference/cross-cutting/, and they load in addition to any language-specific guide when the code under review touches those concerns.

SKILL.md is the entry point; reference/ contains the per-language guides

The skill has no npm package and no CLI entry point. SKILL.md at the repository root is the file that gets registered as a Claude Code skill: it carries the core four-phase process, the severity labeling system and the instruction to pull in language guides when the review calls for them. Supporting files for each language and cross-cutting topic live in reference/ and reference/cross-cutting/.

For setup, the project's documentation at awesome-skills.github.io/code-review-skill/ covers how to configure the skill in Claude Code. The repository itself does not include installation commands in the README, so that documentation page is the correct starting point rather than inferring steps from the file layout.

One structural detail worth noting: the repository contains a .hive/ directory alongside SKILL.md. This appears to be part of the Hive build or documentation system, and it co-exists with the skill files without being part of what gets loaded at review time. The scripts/ directory at the top level handles any build steps for the project's documentation site rather than for the skill itself.

The skill deliberately does not replace linters: automation versus human judgment

One of the six feature points in the README is labeled Automation Awareness: the skill separates what human review should catch from what linters and static analyzers handle. This is a design choice with a practical consequence. If a rule is already enforced by ESLint, clippy, golangci-lint or a CI pipeline, the skill should not duplicate it as a finding, because a reviewer adding noise about things that automated tools already block reduces the signal value of human review.

What remains for the skill is what static analysis cannot check: whether a function does what its name implies, whether an abstraction boundary is in the right place, whether a security risk arises from the combination of two correct-looking components, whether the error handling strategy is consistent with the rest of the codebase. Those are judgment calls, and they are where the language-specific checklists in reference/ focus.

For teams already running comprehensive static analysis, the skill fills the gap that those tools leave. For teams with minimal tooling, the skill may surface findings that a well-configured linter would catch automatically, which is redundant work.

No GitHub releases, last push on 2026-09-08, and MIT under LICENSE

No GitHub releases exist. The last push was on 2026-09-08, and the repository is not archived. A CONTRIBUTING.md covers the process for external contributions, and the PRs Welcome badge in the README signals that new language guides are accepted. A PRs Welcome badge in the README signals that external contributions are accepted.

The MIT licence is in the LICENSE file at the repository root. For a skill file integrated into a development workflow, MIT imposes no constraints on use. Contributing new language guides or extending existing ones under CONTRIBUTING.md's guidelines is the documented path for adding coverage.

Because the skill files are Markdown documents rather than compiled code, the upgrade path is straightforward: pull the latest version of SKILL.md and the reference/ files to get updated guidelines. No build step is required. A potential downside of that same simplicity is that there is no mechanism to pin a specific version of the skill unless you fork the repository or note a commit hash, since there are no versioned release tags to reference.

Editorial conclusion

Use code-review-skill if you work with Claude Code and want a consistent review structure across multiple languages without writing your own prompts for each. Skip it if your review process depends on static analysis rules already enforced by your CI pipeline, since the skill explicitly separates what human review should catch from what linters handle. Before adopting it, read the SKILL.md at the repository root to understand the four-phase process, then check which language guide in reference/ covers your primary stack and how many lines it loads.

Frequently asked questions

Official sources

1. awesome-skills/code-review-skill on GitHub
2. Issues
3. License: MIT
4. Project website
5. README