code-review

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

Updated Jul 31, 2026
One-click install
npx skills add https://github.com/julianckt/adoptarun --skill code-review-julianckt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/julianckt/adoptarun/tree/main/.agents/skills/code-review
Command: npx skills add https://github.com/julianckt/adoptarun --skill code-review-julianckt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — does the code follow the project's standards, and does it actually implement what was asked for — letting one axis mask failures in the other. This Skill separates those concerns into two independent reviews of the same diff. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (documented repo conventions plus a fixed Fowler code-smell baseline) and a Spec review (fidelity to the originating issue or PRD) as parallel sub-agents, then reports them side by side without merging or reranking. - Fixed-point diffing: Reviews changes since any commit, branch, tag, or merge-base the user supplies, validating the ref and diff before spawning reviewers. - Spec discovery: Locates the originating spec from issue references in commit messages, a user-supplied path, or PRD files under docs/, specs/, or .scratch/. - Use Case: Before merging a feature branch, ask for a review since main — you get a Standards report citing violated conventions and possible smells, plus a Spec report listing missing requirements and scope creep. ## Quick Start Ask the assistant to review the changes on this branch since main against the coding standards and the originating issue.

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 branch against coding standards before merging?

Provide a fixed point such as main, a commit SHA, or a tag, and the review computes a three-dot git diff against HEAD. Two parallel sub-agents then check the diff against documented standards and the originating spec, reporting findings side by side.

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

It looks for issue references in commit messages first, then a user-supplied path, then PRD files under docs/, specs/, or .scratch/ matching the branch. If nothing is found, it asks the user, and the Spec axis is skipped when no spec exists.

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 that are not committed yet?

The review works on the diff between HEAD and a fixed point, so uncommitted changes are not included. Commit your work-in-progress first, then specify the fixed point such as main or HEAD~5.

Why are standards and spec findings reported separately?

A change can pass one axis and fail the other — correct code for the wrong requirement, or the right feature written against conventions. Keeping the reports separate prevents one axis from masking failures in the other.