code-review

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

Updated Aug 19, 2026
One-click install
npx skills add https://github.com/PVMalove/claude-agent-harness --skill code-review-pvmalove
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/PVMalove/claude-agent-harness/tree/main/skills/first-party/pvmalove/code-review
Command: npx skills add https://github.com/PVMalove/claude-agent-harness --skill code-review-pvmalove

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — whether the code follows project conventions and whether it actually implements what was asked — letting one axis mask failures in the other. This Skill separates them into independent parallel reviews so neither can hide the other's findings. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (repo conventions plus a fixed Fowler code-smell baseline) and a Spec review (fidelity to the originating issue or spec) as parallel sub-agents, then aggregates both reports side by side. - Fixed-point diffing: Reviews changes since any commit, branch, tag, or merge-base using a three-dot git diff, with upfront validation that the ref resolves and the diff is non-empty. - Spec discovery: Locates the originating spec from issue references in commit messages, a user-supplied path, or files under docs/, specs/, or .scratch/. - Use Case: Before opening a pull request, ask for a review of your feature branch against main and receive separate Standards and Spec verdicts, each with its own findings and worst issue. ## Quick Start Ask the agent to review the changes on my current branch since main against our coding standards and the linked issue spec.

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, branch, or tag, and the review computes a three-dot git diff against HEAD. Two parallel sub-agents then check standards compliance and spec fidelity, and their reports are aggregated side by side.

What happens if there is no spec for the changes being reviewed?▼

The review searches commit messages for issue references, then user-supplied paths, then spec files under docs/, specs/, or .scratch/. If none is found and the user confirms none exists, the Spec axis is skipped and reported as no spec available.

Does the standards review work when a repo has no documented conventions?▼

Yes. A fixed baseline of Fowler code smells from Refactoring chapter 3 always applies, covering issues like Duplicated Code, Feature Envy, and Shotgun Surgery. Documented repo standards override the baseline wherever they conflict.

Can I review work-in-progress changes before opening a pull request?▼

Yes. Any fixed point works, including HEAD~N, a tag, or a branch name, so uncommitted or in-progress work can be reviewed. The ref is validated with git rev-parse and the diff must be non-empty before the sub-agents launch.

Why are standards and spec findings reported separately instead of merged?▼

A change can pass one axis and fail the other, such as clean code implementing the wrong requirement. Keeping the reports separate prevents one axis from masking the other and avoids reranking findings across different concerns.