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.