code-review

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

Updated Aug 13, 2026
One-click install
npx skills add https://github.com/Evolutionary-Leadership/harness --skill code-review-evolutionary-leadership
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/Evolutionary-Leadership/harness/tree/main/.claude/skills/code-review
Command: npx skills add https://github.com/Evolutionary-Leadership/harness --skill code-review-evolutionary-leadership

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a branch or pull request by hand makes it easy to miss either convention violations or unmet requirements, and a single reviewer tends to conflate the two. This Skill splits the review into two independent axes, Standards and Spec, and runs them as parallel sub-agents so neither axis masks the other. ## Core Features & Use Cases - Two-axis review: Checks the diff against documented repo standards plus a built-in Fowler code-smell baseline, and separately against the originating specification or Spec Universe nodes. - Parallel sub-agent judges: Groups changed files by implicated spec nodes and dispatches one judge per group, with a two-tier pass that re-checks drifted or suspect verdicts at a stronger model. - Structured verdict output: Produces a verdict table (matched, drifted, unverifiable), suspect rows, and tier disagreements that downstream gates and PR bodies consume. - Use Case: At the end of a feature branch, run the review against origin/preprod to catch both a naming-convention violation and an acceptance criterion the implementation contradicts before opening the PR. ## Quick Start Ask the assistant to review the changes on this branch since origin/preprod 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 branch against coding standards and its spec automatically?

Run the code-review skill with a fixed point such as a commit SHA, branch, or tag. It diffs HEAD against that point and spawns parallel sub-agents: one checks documented standards and a Fowler smell baseline, the other judges behavior against the specification.

What is the difference between the Standards axis and the Spec axis?

The Standards axis checks whether code follows the repo's documented conventions plus a baseline of Fowler code smells. The Spec axis checks whether the code does what its specification obliges. They are reported separately so one axis never masks a failure in the other.

Can I use this code review outside the /feature workflow?

Yes. Standalone, you specify the fixed point yourself, such as a commit SHA, tag, or HEAD~5. If the repository has no connected specification, the Spec axis falls back to judging against the tracker issue or reports that no spec is available.

What happens when a drifted verdict lacks concrete evidence?

A drifted verdict must name a concrete input and the wrong result it produces. Without that evidence pair, the verdict is downgraded to a suspect row that a person reads; it never enters the verdict table, is never gated on, and is never written to Spec Universe.

Why does the review fail with spec unreachable cannot verify?

That message comes from the Spec Universe client when the service is unreachable (exit 5). The review stops before spawning any judge sub-agents, because judging from memory of the specification rather than the specification as read is not allowed.