code-review

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

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — whether the code follows the repo's standards and whether it actually implements what was asked — letting one concern mask the other. This Skill separates the two axes so a change that passes standards but misses the spec (or vice versa) is caught. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (repo conventions plus a Fowler code-smell baseline) and a Spec review (against the originating issue or PRD) as parallel sub-agents, then reports them side by side. - 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. - Automatic spec discovery: Locates the originating spec from issue references in commit messages, user-supplied paths, 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 code smells, plus a Spec report listing missing requirements and scope creep, each under 400 words. ## Quick Start Ask the assistant to review the changes on this branch since main against the repo's 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 changes since a specific commit or branch?

Provide any fixed point — a commit SHA, branch name, tag, or expression like HEAD~5 — and the review compares it against HEAD using a three-dot git diff from the merge-base. The ref is validated with git rev-parse before the review starts.

How does the code review check against the original issue or spec?

The Spec axis locates the originating spec from issue references in commit messages, a user-supplied path, or PRD files under docs/, specs/, or .scratch/. A dedicated sub-agent then reports missing requirements, scope creep, and incorrect implementations, quoting the spec for each finding.

What coding standards does the review check against?

It checks documented repo standards such as CODING_STANDARDS.md or CONTRIBUTING.md, plus a built-in baseline of Fowler code smells like Duplicated Code, Feature Envy, and Shotgun Surgery. Documented repo standards always override the baseline, and smells are reported as judgement calls.

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

If no spec is found after checking commit messages, user arguments, and docs directories, you are asked where it is. If none exists, the Spec sub-agent is skipped and the final report notes that no spec was available.

Why does the review fail before the sub-agents run?

The fixed point is validated upfront: git rev-parse must resolve the ref and the diff must be non-empty. A bad reference or empty diff fails immediately rather than inside the parallel sub-agents.