How do I install the Code Review skill?

Run npx skillmds@latest add maragudk/code-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Code Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Code Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Code Review free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Code Review?

maragudk (@maragudk) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Code Review by maragudk — Agent Skill

Name: Code Review
Author: maragudk

File contents

Code review

Always start by inspecting the changes. If you're on the main git branch, typically the (staged) git diff. If you're on a different branch, the committed and uncommitted changes compared to the main branch.

Method

Please dispatch two subagents to carefully review the code changes. Run them on the most capable model available: in Claude Code, pass model: fable; in Codex, use gpt-6-astra. Reviewing is where depth pays off, regardless of which model wrote the code. Tell them that they're competing with another agent. Make sure they look at both architecture and implementation. Tell them that whoever finds more issues wins honour and glory.

Also have them run one targeted check on comments: read each new or changed comment as a reader who knows only this package and the public API of what it imports. Flag any mention of callers or importing packages, and any reference to internals hidden behind an abstraction the code consumes. Such context leakage is a real defect, not a comment nitpick -- surface it even when only one reviewer finds it.

Run a second targeted check on constants: flag any new package-level constant (or variable) that is used in only one place, or only within a single function. The fix is to inline the value at its use site, until a constant is genuinely needed -- reuse across functions, or a name that adds real meaning the literal lacks. Surface this even when only one reviewer finds it.

Surfacing issues

Signal-to-noise ratio matters more than completeness. When reporting back to the caller:

By default, only surface issues that both sub-agents independently found. Agreement between two reviewers is a strong signal that an issue is real.
Drop issues that only one sub-agent raised, unless the issue is serious -- e.g. a correctness bug, security flaw, data-loss risk, concurrency hazard, or significant architectural problem. Serious issues get surfaced even without corroboration.
Minor issues and nitpicks (style preferences, naming bikesheds, comment suggestions, micro-optimisations) should only be surfaced when both sub-agents flagged them.

State clearly in the report which issues had consensus and which are single-reviewer calls promoted for seriousness.

---name: code-reviewdescription: Guide for making code reviews. Use this when asked to make code reviews, or ask to use it before committing changes.license: MIT---# Code reviewAlways start by inspecting the changes. If you're on the `main` git branch, typically the (staged) git diff. If you're on a different branch, the committed and uncommitted changes compared to the main branch.## MethodPlease dispatch two subagents to carefully review the code changes. Run them on the most capable model available: in Claude Code, pass `model: fable`; in Codex, use `gpt-6-astra`. Reviewing is where depth pays off, regardless of which model wrote the code. Tell them that they're competing with another agent. Make sure they look at both architecture and implementation. Tell them that whoever finds more issues wins honour and glory.Also have them run one targeted check on comments: read each new or changed comment as a reader who knows only this package and the public API of what it imports. Flag any mention of callers or importing packages, and any reference to internals hidden behind an abstraction the code consumes. Such context leakage is a real defect, not a comment nitpick -- surface it even when only one reviewer finds it.Run a second targeted check on constants: flag any new package-level constant (or variable) that is used in only one place, or only within a single function. The fix is to inline the value at its use site, until a constant is genuinely needed -- reuse across functions, or a name that adds real meaning the literal lacks. Surface this even when only one reviewer finds it.## Surfacing issuesSignal-to-noise ratio matters more than completeness. When reporting back to the caller:- By default, only surface issues that **both** sub-agents independently found. Agreement between two reviewers is a strong signal that an issue is real.- Drop issues that only one sub-agent raised, unless the issue is **serious** -- e.g. a correctness bug, security flaw, data-loss risk, concurrency hazard, or significant architectural problem. Serious issues get surfaced even without corroboration.- Minor issues and nitpicks (style preferences, naming bikesheds, comment suggestions, micro-optimisations) should only be surfaced when both sub-agents flagged them.State clearly in the report which issues had consensus and which are single-reviewer calls promoted for seriousness.

Frequently asked questions

Code Review