Code Review and Refactoring Skills

Best for: Stress-testing a plan or design before any code gets written

The fifth most installed skill in the entire registry, from TypeScript educator Matt Pocock. Invoke it and the agent interviews you relentlessly about every aspect of your plan, walking down each branch of the design tree and resolving dependencies between decisions one by one. Questions come strictly one at a time, each with the agent's own recommended answer attached, and nothing gets built until you confirm a shared understanding.

The instruction that makes it work: facts the agent can find by exploring the codebase get looked up, while decisions belong to you and get put to you explicitly. That split keeps the interview about the choices that matter. The grill-me command is a thin launcher for the underlying grilling skill in the same repo, and its sibling grill-with-docs, at another 434K installs, applies the same treatment with documentation lookups mixed in.

• 518K installs, the biggest name in agent code quality
• One question at a time, each with a recommended answer
• Looks up facts in the codebase, asks you only for decisions
• Blocks implementation until shared understanding is confirmed

Best for: Checking a branch against both repo standards and the original spec

Reviews the diff between HEAD and a fixed point you name, a branch, tag, SHA, or merge-base, along two axes at once. The Standards sub-agent checks conformance with the repo's documented coding standards; the Spec sub-agent checks whether the code faithfully implements the originating issue or PRD, hunting for the spec through commit message references, docs folders, and branch names.

Both reviews run as parallel sub-agents so neither pollutes the other's context, then the skill aggregates the findings side by side. It also validates its inputs before spending tokens: the fixed point must resolve and the diff must be non-empty, or it fails fast instead of inside two running reviewers. The spec axis is the differentiator; most review setups check style and correctness but never ask whether the code does what the ticket asked.

• Standards and spec reviewed in parallel, reported side by side
• Finds the spec via commit references, docs, and branch names
• Three-dot diff against the merge-base, validated before running
• Sub-agent isolation keeps the two reviews independent

Best for: Killing the noise in AI review comments

The most common complaint about AI code review is verbosity: paragraphs of hedging around every nitpick. caveman-review's answer is a hard format: one line per finding, structured as location, problem, fix. L42: user can be null after .find(). Add guard before .email. Optional severity prefixes separate bugs from risks from nits from genuine questions.

The SKILL.md is mostly a list of what to delete: I noticed that, you might want to consider, this is just a suggestion but, per-comment praise, restating what the line does, and every hedge word. What survives is exact line numbers, exact symbol names in backticks, and a concrete fix. At 229K installs, a lot of developers apparently wanted their reviewer to stop talking.

• Hard one-line format per finding, with severity prefixes
• Bans hedging, filler praise, and restating the diff
• Requires exact line numbers and concrete fixes
• Part of the caveman suite of compression skills

Best for: Stopping an agent from rubber-stamping its own work

An agent reviewing code it just wrote inherits every assumption that produced the bugs. This skill from Jesse Vincent's superpowers methodology breaks that loop: it dispatches a separate reviewer subagent that receives precisely crafted context, the description, the requirements, and the base and head commit SHAs, and never the authoring session's history.

Review is mandatory after each task in subagent-driven development, after major features, and before merging, with findings triaged as Critical to fix immediately, Important to fix before proceeding, and Minor to note for later. The skill even encourages pushing back on the reviewer with reasoning when it is wrong, which pairs naturally with its sibling below.

• Reviewer subagent gets clean context, never session history
• Reviews pinned to exact base and head commit SHAs
• Critical, Important, and Minor triage for findings
• Part of superpowers, the most starred skill methodology

Best for: Handling review feedback without blind compliance

The other half of the review loop: what the agent does with feedback. The response pattern is read completely, restate the requirement, verify it against codebase reality, evaluate whether it is technically sound for this codebase, then respond or push back. Implementation happens one item at a time with a test after each.

Its forbidden-responses list reads like a direct patch for agent behavior everyone has seen: You're absolutely right! and Great point! are banned outright as performative agreement. If any feedback item is unclear, the agent stops and asks before implementing anything, because partially understood feedback produces wrong implementations. External reviewer suggestions get extra scrutiny, including checks for whether the reviewer understood the full context.

• Bans performative agreement phrases explicitly
• Feedback verified against the codebase before any change
• Unclear items stop everything until clarified
• Extra scrutiny path for external reviewer suggestions

Best for: Wiring agent review into automated PR workflows

Warp's skill treats review as a pipeline stage. The agent reviews a checked-out PR from local artifacts, the diff and description as text files, plus optional spec context, and writes structured findings to review.json for the surrounding workflow to publish. It never posts to GitHub directly, which is exactly what you want when the workflow controls what appears on the PR.

The review rules encode hard-won CI lessons: style nits are only allowed with a concrete suggestion block attached, concerns about untouched code go in the summary instead of inline comments, test suggestions must exercise a genuinely distinct code path, and robustness ideas on a V0 implementation get framed as future work rather than blockers. Small install count, but it is the most production-shaped review skill in the registry.

• Outputs structured review.json instead of posting comments
• Optional spec-drift checking against provided spec context
• Nits require a concrete suggestion block to be included
• Built by Warp for real CI review pipelines

Best for: A complete review discipline in one skill

Addy Osmani's take runs every change through five axes: correctness, readability, architecture, security, and performance. The readability axis carries two questions most reviews skip: could this be done in fewer lines, and are the abstractions earning their complexity, with a rule against generalizing before the third use.

What sets it apart is the approval standard, borrowed from how Google runs reviews: approve when the change definitely improves overall code health, even if it is imperfect, and never block a change for being different from how you would have written it. That single sentence fixes the over-blocking behavior that makes agent reviewers exhausting. At 3,200 words it is the most thorough review rulebook in this list.

• Five review axes with concrete checklists each
• Approval bar: definitely improves code health, even if imperfect
• Abstractions must earn their complexity, no early generalizing
• Written by a Chrome team engineering leader

Best for: Finding the refactors that actually pay for themselves

At 428K installs, the standard tool for architectural refactoring with an agent. It scans a codebase for what it calls deepening opportunities: refactors that turn shallow modules, where the interface is nearly as complex as the implementation, into deep ones, aiming at testability and AI-navigability. Suspected shallow modules face the deletion test: would deleting this concentrate complexity, or just move it around?

Findings arrive as a self-contained HTML report written to the temp directory, keeping the repo clean, and the skill builds on a shared design vocabulary from its companion codebase-design skill: module, interface, depth, seam, adapter, leverage, locality. Pick an opportunity and it grills you through the decision before touching code, reusing the same interview discipline as grill-me.

• Hunts shallow modules with the deletion test
• Visual HTML report of ranked refactoring candidates
• Shared design vocabulary via the codebase-design skill
• Grills you through the chosen refactor before executing

Best for: A refinement pass right after the agent writes code

From Brian Lovin, the designer-engineer behind Campsite. This one runs after code is written and changes only how the code does things, never what it does: reducing nesting, cutting redundant abstractions, deleting comments that describe obvious code, and applying the project's own standards from CLAUDE.md.

The interesting half is the restraint. It explicitly warns against over-simplification: no clever dense one-liners, no nested ternaries, no combining concerns to save lines, and no removing abstractions that were organizing things well. Readable and explicit beats compact, which is precisely the correction agent-written code tends to need after a long session.

• Strict rule: never change behavior, only clarity
• Applies the project's own CLAUDE.md standards
• Explicit guardrails against clever over-compression
• Cheap to run after every substantial agent edit

Best for: Breaking the guess-and-patch loop on any bug

Its core rule is stated as an Iron Law: no fixes without root cause investigation first. Phase one alone covers reading the complete error output, reproducing the issue consistently, checking what recently changed, and, in multi-component systems, adding diagnostic instrumentation at each component boundary to see what data actually crosses it before proposing anything.

The skill is bluntest about the situations where agents and humans both cave: emergencies, the obvious one-line fix, and the third attempt after two failed patches. Its position is that systematic is faster than thrashing, especially under time pressure. With 182K installs it has become the default answer to agents that fix symptoms in a loop while the actual bug survives.

• Iron Law: root cause investigation before any fix
• Four gated phases, each must complete before the next
• Boundary instrumentation for multi-component systems
• Aimed at exactly the moments everyone skips process