code-review

Reviews a git diff against coding standards and the originating spec using parallel sub-agents.

2|Updated Jul 11, 2026
One-click install
npx skills add https://github.com/MoofonLi/dev-ready --skill code-review-moofonli
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/MoofonLi/dev-ready/tree/main/.agents/skills/code-review
Command: npx skills add https://github.com/MoofonLi/dev-ready --skill code-review-moofonli

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a branch or PR requires checking two independent things — whether the code follows the repo's documented standards and whether it actually implements what the issue or PRD asked for — and doing both in one pass lets one concern mask the other. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (documented repo standards plus a fixed Fowler code-smell baseline) and a Spec review (requirements coverage, scope creep, incorrect implementations) as parallel sub-agents that don't pollute each other's context. - Fixed-point diffing: Reviews the changes since any commit, branch, tag, or merge-base the user supplies, validating the ref and diff before spawning reviewers. - Spec source discovery: Locates the originating spec from issue references in commit messages, a user-provided path, or PRD files under docs/, specs/, or .scratch/. - Use Case: Before merging a feature branch, ask for a review since main and receive side-by-side Standards and Spec reports, each citing the violated rule or spec line. ## Quick Start Ask the agent to review the changes on this branch since main using the code-review skill.

Frequently Asked Questions about code-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a git branch against coding standards and a spec?

Provide a fixed point such as a commit SHA, tag, or main, and the skill diffs it against HEAD using a three-dot merge-base comparison. It then runs two parallel sub-agents: one checks documented standards plus a code-smell baseline, the other checks the originating issue or PRD.

How does the review find the spec or issue for a branch?

It looks for issue references in commit messages first, then a user-provided path, then PRD files under docs/, specs/, or .scratch/ matching the branch or feature. If no spec exists, the Spec axis is skipped and reported as unavailable.

What code smells does the standards review check for?

The baseline covers twelve Fowler smells including Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Shotgun Surgery, and Speculative Generality. Each is reported as a labelled judgement call, and documented repo standards always override the baseline.

Can I review work-in-progress changes instead of a finished PR?

Yes, any fixed point works, including HEAD~5, a tag, or a branch name. The skill validates that the ref resolves and the diff is non-empty before spawning the review sub-agents, so bad refs fail early.

Why are standards and spec findings reported separately?

A change can pass one axis and fail the other: code may follow every standard but implement the wrong thing, or match the spec while breaking conventions. Keeping the reports separate prevents one axis from masking the other, and findings are never merged or reranked.