code-review

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

Updated May 31, 2026
One-click install
npx skills add https://github.com/AlexanderNarbaev/agi --skill code-review-alexandernarbaev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/AlexanderNarbaev/agi/tree/main/.opencode/skills/matt-pocock/code-review
Command: npx skills add https://github.com/AlexanderNarbaev/agi --skill code-review-alexandernarbaev

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 — letting one axis mask failures in the other. This Skill separates them into independent parallel reviews so neither hides the other's findings. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (repo-documented conventions plus a fixed Fowler code-smell baseline) and a Spec review (requirements coverage, scope creep, incorrect implementations) as parallel sub-agents. - Fixed-point diffing: Reviews changes since any commit, branch, tag, or merge-base using 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, user-provided paths, or files under docs/, specs/, or .scratch/. - Use Case: Before merging a feature branch, ask for a review since main and receive side-by-side Standards and Spec reports, each listing findings with quoted evidence and a per-axis summary. ## Quick Start Ask the assistant to review the changes on this branch since main 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 or PR against coding standards and its spec?

Provide a fixed point such as a commit SHA, branch, tag, or main, and the skill diffs HEAD against it using three-dot git diff. It then runs two parallel sub-agents: one checks the diff against documented standards and a Fowler code-smell baseline, the other checks it against the originating spec.

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, Divergent Change, and Speculative Generality. Each is treated as a labelled judgement call, and documented repo standards always override the baseline.

How does the review find the spec for a change?

It looks for issue references in commit messages first, then a user-provided path, then spec files under docs/, specs/, or .scratch/ matching the branch or feature. If no spec exists, the Spec axis is skipped and reported as unavailable.

What happens if the fixed point or diff is invalid?

The skill validates the ref with git rev-parse and confirms the diff is non-empty before spawning any sub-agents. A bad ref or empty diff fails immediately at that step rather than inside the parallel reviews.

Why are standards and spec findings reported separately?

A change can pass one axis and fail the other, such as clean code implementing the wrong thing. Keeping the reports separate prevents one axis from masking the other, so findings are never merged or reranked across axes.