# Agents and skills for code review

> Review diffs, catch bugs before the merge and reduce technical debt.

- Source: https://doutorai.pt/en/for/code-review
- Site: Doutor AI (https://doutorai.pt/en) - AI tools for small businesses

Code review is the moment when someone, or something, looks at a change before it goes into the main branch. On a small project, a quick read of the diff is enough. The trouble starts when the repository grows, when several people touch the same files and when part of the code starts being written by assistants: the volume of changes goes up and human attention cannot keep pace.

The components on this page give Claude Code a defined role at that moment. One agent reads the diff and returns issues with file and line, another looks only for security flaws, another checks whether the tests really cover the new path. There are skills that post inline comments on the pull request and automations that run the linter on every file edit, before a review even exists.

Start with the general-purpose reviewer and the linting automation, which cover most cases with little setup. Only then add specialized reviewers, and only the ones that match real risks in your project: security, architecture, API contracts, test coverage. For old code, the refactoring and technical debt agents are a different path, slower and more deliberate.

21 hand-picked components, from 4 different angles.

## Review changes before they go into the main branch

Reviewers that work on a diff or a pull request. They cover the moment when the code is ready but has not been merged yet.

- **code-reviewer** (Agents): A good starting point if you have no reviewer set up yet: it analyzes the changes submitted in a pull request and classifies quality, security and best-practice issues. [page](https://doutorai.pt/en/components/agents__code-reviewer)
- **review-local-changes** (Skills): For work that has not left your machine yet: it reads the git diff and the untracked files and returns suggestions before a commit even exists. [page](https://doutorai.pt/en/components/skills__neolab-context-engineering-kit__review-local-changes)
- **review-pr** (Skills): When the change is already in a GitHub pull request, it posts the comments directly on the diff lines through gh, instead of leaving them in the terminal. [page](https://doutorai.pt/en/components/skills__neolab-context-engineering-kit__review-pr)
- **bug-hunter** (Agents): Focuses only on bugs and critical issues, with root cause analysis. It helps when a generic review returns lots of style notes and little substance. [page](https://doutorai.pt/en/components/agents__neolab-context-engineering-kit__agents-bug-hunter)
- **adversarial-reviewer** (Skills): For when you suspect the model is agreeing too readily with the code it just wrote: it uses hostile reviewer personas to expose blind spots it shares with the author. [page](https://doutorai.pt/en/components/skills__alirezarezvani-claude-skills__adversarial-reviewer)
- **reviewer** (Agents): A second opinion generated by a model from another family, in read-only mode. It makes sense for contested diffs or sensitive changes, where two opinions are worth having. [page](https://doutorai.pt/en/components/agents__davepoon-subagents__agents-reviewer)

## Reviews from a specialized angle

Each of these reviewers looks at just one dimension of the code. Use them when a generic review is not enough, or in parallel on a project with concrete risks.

- **architect-reviewer** (Agents): Looks at the change from a structural point of view: layers, SOLID principles and consistency with existing patterns. A good fit for pull requests that change how the code is organized. [page](https://doutorai.pt/en/components/agents__architect-reviewer)
- **se-security-reviewer** (Agents): When the diff touches authentication, user input or sensitive data, it applies the OWASP Top 10 and enterprise security criteria instead of generic comments. [page](https://doutorai.pt/en/components/agents__se-security-reviewer)
- **test-coverage-reviewer** (Agents): Checks whether the tests that come with the change really cover the new functionality and the edge cases, instead of just pushing up the coverage percentage. [page](https://doutorai.pt/en/components/agents__neolab-context-engineering-kit__agents-test-coverage-reviewer)
- **contracts-reviewer** (Agents): Built for changes to public APIs, data models, database schemas and type definitions, where a design mistake is expensive to undo later. [page](https://doutorai.pt/en/components/agents__neolab-context-engineering-kit__agents-contracts-reviewer)
- **multi-reviewer-patterns** (Skills): If you run several reviewers in parallel, it handles the tedious part: it removes duplicate findings, calibrates severity and merges everything into a single report. [page](https://doutorai.pt/en/components/skills__wshobson-agents__multi-reviewer-patterns)

## Refactor and reduce technical debt

Here the goal is not to approve or reject a change, it is to improve code that already exists without changing what it does.

- **refactoring-specialist** (Agents): Designed for code nobody wants to touch: huge methods, duplicated logic, confusing structure. It rewrites while preserving the existing behavior. [page](https://doutorai.pt/en/components/agents__refactoring-specialist)
- **code-simplifier** (Agents): Works on recently changed code and reduces complexity without changing functionality. It fits well as the next step after a review that flagged a lot of unclear code. [page](https://doutorai.pt/en/components/agents__code-simplifier)
- **technical-debt-manager** (Agents): For whoever has to decide what goes into the next sprint: it assesses the health of the code and proposes a refactoring order, instead of treating debt as an endless list. [page](https://doutorai.pt/en/components/agents__technical-debt-manager)
- **unused-code-cleaner** (Agents): Removing a feature always leaves something behind: imports, functions and classes nobody calls anymore. It detects them in several languages and removes them with safety checks. [page](https://doutorai.pt/en/components/agents__unused-code-cleaner)
- **deslop** (Skills): Made for branches written with AI help: it compares against the main branch and strips out excess comments, unnecessary defensive checks and type casts to any. [page](https://doutorai.pt/en/components/skills__deslop)

## Make review part of the routine

Automations, commands and connectors that make the repetitive work happen without anyone having to remember it.

- **lint-on-save** (Automations): Runs ESLint, Pylint or RuboCop right after every file edit, so formatting and style errors never reach the actual review. [page](https://doutorai.pt/en/components/hooks__lint-on-save)
- **setup-linting** (Commands): Handles the initial setup of static analysis tools on a project that has none yet, with language detection and automatic application of the rules. [page](https://doutorai.pt/en/components/commands__setup-linting)
- **code-review-checklist** (Skills): A checklist for teams that want the same criteria in every review, with sections for functionality, security, performance and maintainability. [page](https://doutorai.pt/en/components/skills__code-review-checklist)
- **receiving-code-review** (Skills): The other side of the table: how to evaluate review comments that seem debatable, checking before implementing instead of accepting everything out of deference. [page](https://doutorai.pt/en/components/skills__receiving-code-review)
- **codacy** (Connectors): A connector for the Codacy API that gives Claude Code access to the quality, coverage and security reports the platform has already gathered about the repository. [page](https://doutorai.pt/en/components/mcps__codacy)

## How to install each type of component

Agents are markdown files that you put in .claude/agents/ inside the project, or in ~/.claude/agents/ if you want them in every repository. Skills follow the same logic in .claude/skills/ and are triggered by the intent of the request, without needing a command. Commands go in .claude/commands/ and become available with a slash. Automations live in the settings.json file, in the hooks section, and run on their own after each edit. MCP connectors are added to the MCP server configuration and usually ask for a token from the platform. After copying any of these files, restart the session so Claude Code picks it up.

## Combining several reviewers without creating noise

The most common mistake is to install six reviewers and start getting hundred-line reports that nobody reads. A sequence that works: automatic linting on every save, a general-purpose reviewer on local changes before the commit, and only then one or two specialized reviewers chosen by what the change touches. If the diff touches authentication, call the security reviewer. If it changes schemas or public types, call the contracts reviewer. When you run more than two in parallel, use a consolidation skill to merge repeated findings and standardize severity, otherwise the same issue shows up described in three different ways.

## What these reviews do not solve

An automated reviewer reads what is in the diff. It does not know what the client asked for, or why that defensive function was written two years ago, or whether the feature makes sense for the business. It also tends to produce low-value findings when you do not give it enough project context, and to agree with code the model itself wrote, which is exactly why adversarial and second-opinion reviewers exist. Treat the reports as a first pass that catches the obvious and frees up human attention for the decisions that need context: design, priorities and real risk.

## Keep reading

- [Code Reviewer Agent](https://doutorai.pt/en/how-to/subagents--code-reviewer)
- [Clean Code Reviewer Agent](https://doutorai.pt/en/how-to/subagents--clean-code-reviewer)
- [Clean Code Rules for AI Code Generation](https://doutorai.pt/en/how-to/clean-code-rules)

## Frequently asked questions

### What is the difference between a review agent and a review skill?

An agent runs in its own session, with its own separate context, and returns a report at the end. It is useful for long reviews that should not clutter the main conversation. A skill loads instructions into the current session when the request matches its description, and is better suited to short procedures, such as applying a checklist or posting comments on a pull request.

### Do I need to install all these components in the same project?

No, and you probably should not. Two or three are enough for most repositories: a general-purpose reviewer, a linting automation and, if the project has concrete risk in that area, a security reviewer. The rest make sense as the code grows or when a problem comes up that justifies them.

### Does this replace review by teammates?

It does not. It lets you reach the human review with the obvious already handled: formatting, unused imports, type errors, missing checks. What is left for people are the decisions that need context about the product and the project's history, which is where human review is still worth the most.

### Does it make sense to review code that Claude Code itself wrote?

It does, and that is where the choice of reviewer matters. A model tends to accept its own reasoning, so it is worth using an adversarial reviewer, or one that runs on another model, for a second opinion. There are also skills dedicated to cleaning up typical patterns of generated code, such as excess comments and unnecessary defensive checks.

### What if the repository is not hosted on GitHub?

Most of these components work on the local git diff, so they work with any hosting, including self-hosted servers. The exceptions are the skills and connectors that post inline comments, which depend on the GitHub API. In that case you can keep reviewing locally and paste the report into the platform you use.

---
Content by Doutor AI (https://doutorai.pt/en). When quoting, please cite the source: https://doutorai.pt/en/for/code-review