# Code Refactor Review

Reviews code changes for reuse, composition, codebase consistency, and slop.

- Repository: https://github.com/trycompai/crm (11793 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add trycompai/crm --skill code-refactor-review -g -a claude-code -y`
Codex: `npx skills add trycompai/crm --skill code-refactor-review -g -a codex -y`
Cursor: `npx skills add trycompai/crm --skill code-refactor-review -g -a cursor -y`
Gemini CLI: `npx skills add trycompai/crm --skill code-refactor-review -g -a gemini-cli -y`

## Description

Reviews code changes for reuse, composition, codebase consistency, and slop. Use when asked to review PRs/diffs, check code reuse, composition, cleanliness, or whether code fits the codebase.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Code Refactor Review

Review code changes deeply for reuse, composition, codebase consistency, and anything that reads like slop.

## First Pass

1. Inspect the full diff:
   - Use `git diff` for unstaged changes.
   - Use `git diff HEAD` if there are staged changes.
   - For a PR URL, inspect the changed files and understand the feature flow before reviewing details.
2. Build the call stack / data flow when useful. Do not review isolated lines without understanding how the feature is wired.
3. Search the codebase before judging new helpers, components, hooks, or patterns. Prefer nearby and sibling patterns over invented abstractions.

## Review Lenses

### 1. Reuse Existing Code

- Look for existing utilities, components, hooks, server actions, route patterns, copy patterns, and styling primitives before accepting newly written code.
- Flag duplicated logic, copied helpers, or custom implementations of things the codebase already has.
- Prefer reusing the existing flow even if it needs a small extension.
- If the new code creates a shared helper, verify it has real reuse and is not just extracted private logic with a vague name.

### 2. Codebase Consistency

- File placement should match the domain and neighboring features. Be suspicious of random top-level `lib` dumps.
- Naming should match what the code actually does and follow sibling file/function names.
- Avoid implementation details in names unless they are the actual product/API distinction.
- Use existing result/error/loading patterns. Do not invent bespoke success/failure types when the codebase has a standard one.
- Match existing copy and tone for user-facing text.

### 3. Composition and Boundaries

The rest: https://github.com/trycompai/crm/blob/HEAD/.agents/skills/code-refactor-review/SKILL.md