code-review

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

2|Updated May 12, 2026
One-click install
npx skills add https://github.com/tajo9128/BioDockify-Pharma-AI --skill code-review-tajo9128
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/tajo9128/BioDockify-Pharma-AI/tree/main/.agents/skills/code-review
Command: npx skills add https://github.com/tajo9128/BioDockify-Pharma-AI --skill code-review-tajo9128

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — whether code follows project conventions and whether it implements what was actually requested — causing one axis to mask failures in the other. This Skill separates those concerns into independent parallel reviews so neither axis hides the other's findings. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (documented repo standards plus a Fowler code-smell baseline) and a Spec review (requirements from the originating issue or spec file) as parallel sub-agents with isolated contexts. - Fixed-point diffing: Pins any commit, branch, tag, or merge-base as the comparison point and validates it before spawning reviewers. - Spec discovery: Automatically locates the originating spec from issue references in commit messages, user-provided paths, or spec 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 summarized separately. ## Quick Start 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 compares HEAD against it using git diff with three-dot merge-base syntax. Two parallel sub-agents then check standards compliance and spec fidelity independently, reporting findings side by side.

How does the review find the originating issue or spec?

It first scans commit messages for issue references like #123 or Closes #45, then checks for a user-provided path, then searches docs/, specs/, or .scratch/ for a matching spec file. If nothing is found, it asks the user or reports that no spec is available.

What code smells does the standards review check for?

The baseline covers Fowler's Refactoring smells including Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Shotgun Surgery, Divergent Change, Speculative Generality, Message Chains, Middle Man, and Refused Bequest. Documented repo standards always override the baseline.

Can I review work-in-progress changes that are not committed yet?

The review operates on git diffs between a fixed point and HEAD, so changes must be committed to appear in the comparison. Uncommitted working-tree changes are not part of the diff produced by git diff <fixed-point>...HEAD.

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

A change can pass one axis and fail the other — code can follow every convention but implement the wrong thing, or match the spec while breaking project standards. Keeping the reports separate prevents one axis from masking failures in the other.