code-review

Reviews git diffs against coding standards and originating specs using parallel sub-agents.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/MSC72m/DevForge --skill code-review-msc72m
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/MSC72m/DevForge/tree/main/skills/code-review
Command: npx skills add https://github.com/MSC72m/DevForge --skill code-review-msc72m

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a branch or PR requires checking two separate things at once: whether the code follows the repo's documented standards and whether it actually implements what the issue or spec asked for. Doing both in one pass causes one axis to mask the other, and findings get lost or reranked incorrectly. ## Core Features & Use Cases - Two-axis parallel review: Spawns separate Standards and Spec sub-agents so each review runs in isolated context, then aggregates findings side by side without merging or reranking. - Fowler smell baseline: Applies a fixed set of code smells from Refactoring (Duplicated Code, Feature Envy, Shotgun Surgery, etc.) even when the repo documents no standards, with repo standards always overriding the baseline. - Automatic spec discovery: Locates the originating spec from issue references in commit messages, user-provided paths, or spec files under docs/, specs/, or .scratch/. - Use Case: Before merging a feature branch, ask for a review since main and receive a report with a Standards section citing violated conventions and a Spec section listing missing requirements and scope creep. ## Quick Start Ask the assistant to review the changes since main using the code-review skill and report standards and spec findings side by side.

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 its spec?▼

Provide a fixed point such as a commit SHA, branch, or tag, and the skill diffs it against HEAD using a three-dot merge-base comparison. It then runs Standards and Spec reviews as parallel sub-agents and reports both sets of findings side by side.

How does automated code review find the originating spec or issue?▼

Spec discovery checks issue references in commit messages first, then a user-provided path, then spec files under docs/, specs/, or .scratch/ matching the branch name. If nothing is found, the user is asked, and the Spec axis is skipped when no spec exists.

What happens if a repo has no documented coding standards?▼

The Standards axis falls back to a fixed baseline of Fowler code smells from Refactoring chapter 3, such as Duplicated Code, Feature Envy, and Shotgun Surgery. These are reported as labelled judgement calls rather than hard violations.

Can a documented repo standard override the code smell baseline?▼

Yes, documented repo standards always win over the baseline. Where a repo standard endorses something the baseline would flag, the smell is suppressed, and anything already enforced by tooling is skipped entirely.

Why does the review fail before the sub-agents run?▼

The fixed point is validated first with git rev-parse, and the diff is confirmed to be non-empty. A bad ref or empty diff fails at this pinning step rather than inside the parallel sub-agents.