How do I install the Code Review skill?

Run npx skillmds@latest add dmoreq/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. Capability flags: docs only. 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, and the skill stays under its author's original license.

Who published Code Review?

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

Code Review by dmoreq — Agent Skill

Name: Code Review
Rating: 4.2 (5 reviews)
Author: dmoreq

File contents

Code Review Skill

Rigorous, constructive review of a concrete diff. Review the code, not the author. Zero comments is valid when the diff is good.

When to Use

Pull requests or local diffs
Quality gate before merging behavior or public-API changes
Looking for bugs, security issues, or missing tests
Peer-review step for non-trivial subagent code deliverables (diff + contract only)

When Not to Use

No code change to review
Pure design discussion without a diff (doubt-driven-development / python-patterns)
Starting a feature from scratch (implement first via python-pro / rust-pro, then review)

After findings: implement fixes via the language skill. Do not refuse the repair loop.

Related Skills

Use code-simplification when the main issue is structural complexity, not a bug.
Use deprecation-migration when the diff (or review) surfaces a zombie API that should be sunset.
Use python-testing or crate tests when behavior changed without tests.

Language style encyclopedias live in python-pro, rust-pro, and rust-async-patterns. This skill checks that they were applied.

Review Principles

Evidence-based, actionable comments
Distinguish severity
Explain why
Teach when it is cheap

Severity (text only — no emoji)

Critical — must fix before merge (bugs, security, data loss, undefined behavior)
Important — should fix (quality, performance, maintainability)
Suggestion — nicer alternative
Nit — style; label as nit

Universal Checklist

Correctness: does what it claims; edge and error paths; no obvious races.

Safety & Security: inputs validated; no injection; no hardcoded secrets; errors do not leak secrets.

Performance: no obvious extra work on hot paths; I/O/allocs reasonable; concurrency used correctly.

Maintainability: readable names; complex logic explained or simplified; public APIs intentional.

Testing: important paths and edges covered; tests assert behavior, not coverage theater.

Language Pointers

Python: python-pro + ruff; no mutable defaults; no bare except:; context managers; pathlib.
Rust: rust-pro; no .unwrap() in non-test prod; // SAFETY: on unsafe; no locks across .await (rust-async-patterns).

Output Format

Summary — 1–3 sentences
Findings — Critical → Nit
Positive notes — if any
Questions — if any

Each finding: severity, file:line, description, suggested fix, why it matters.

Tone

Direct, professional, constructive. Prefer “This can cause…” over “You should…”.

---name: code-reviewdescription: Review a code diff before merge: correctness, safety, performance, tests, public API. Not the first skill for implementing features. After findings, hand off fixes to the language skill.---# Code Review SkillRigorous, constructive review of a concrete diff. Review the code, not the author. Zero comments is valid when the diff is good.## When to Use- Pull requests or local diffs- Quality gate before merging behavior or public-API changes- Looking for bugs, security issues, or missing tests- Peer-review step for non-trivial subagent code deliverables (diff + contract only)## When Not to Use- No code change to review- Pure design discussion without a diff (`doubt-driven-development` / `python-patterns`)- Starting a feature from scratch (implement first via `python-pro` / `rust-pro`, then review)After findings: implement fixes via the language skill. Do not refuse the repair loop.## Related Skills- Use **code-simplification** when the main issue is structural complexity, not a bug.- Use **deprecation-migration** when the diff (or review) surfaces a zombie API that should be sunset.- Use **python-testing** or crate tests when behavior changed without tests.Language style encyclopedias live in `python-pro`, `rust-pro`, and `rust-async-patterns`. This skill checks that they were applied.## Review Principles- Evidence-based, actionable comments- Distinguish severity- Explain *why*- Teach when it is cheap## Severity (text only — no emoji)- **Critical** — must fix before merge (bugs, security, data loss, undefined behavior)- **Important** — should fix (quality, performance, maintainability)- **Suggestion** — nicer alternative- **Nit** — style; label as nit## Universal Checklist**Correctness:** does what it claims; edge and error paths; no obvious races.**Safety & Security:** inputs validated; no injection; no hardcoded secrets; errors do not leak secrets.**Performance:** no obvious extra work on hot paths; I/O/allocs reasonable; concurrency used correctly.**Maintainability:** readable names; complex logic explained or simplified; public APIs intentional.**Testing:** important paths and edges covered; tests assert behavior, not coverage theater.## Language Pointers- **Python:** `python-pro` + ruff; no mutable defaults; no bare `except:`; context managers; `pathlib`.- **Rust:** `rust-pro`; no `.unwrap()` in non-test prod; `// SAFETY:` on unsafe; no locks across `.await` (`rust-async-patterns`).## Output Format1. **Summary** — 1–3 sentences2. **Findings** — Critical → Nit3. **Positive notes** — if any4. **Questions** — if anyEach finding: severity, file:line, description, suggested fix, why it matters.## ToneDirect, professional, constructive. Prefer “This can cause…” over “You should…”.

Frequently asked questions

Code Review