code-review

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

Updated Jan 19, 2023
One-click install
npx skills add https://github.com/inkfin/dotfiles --skill code-review-inkfin
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/inkfin/dotfiles/tree/main/dot_agents/skills/exact_code-review
Command: npx skills add https://github.com/inkfin/dotfiles --skill code-review-inkfin

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a branch or PR requires checking two independent things at once — whether the code follows the repo's documented standards and whether it actually implements what the spec or ticket asked for — and mixing both in one pass lets one axis mask failures in the other. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (documented repo standards plus a fixed Fowler code-smell baseline) and a Spec review (requirements coverage, scope creep, wrong implementations) as parallel sub-agents, then reports them side by side without merging or reranking. - Fixed-point diffing: Compares HEAD against any user-supplied commit, branch, tag, or merge-base using three-dot diff, validating the ref and non-empty diff before spawning agents. - Spec discovery: Locates the originating spec from a user-provided path, plans/<feature>/spec.md, plans/<feature>/issues/, or docs/ and specs/ directories. - Use Case: Before merging a feature branch, ask for a review since main and receive separate Standards and Spec reports, each under 400 words, with a one-line summary of findings per axis. ## Quick Start Ask the assistant to review the changes since main against the spec in plans/my-feature/spec.md.

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?

Provide a fixed point such as a commit SHA, branch, tag, or main, and the review diffs HEAD against it using a three-dot merge-base comparison. Two parallel sub-agents check standards compliance and spec fidelity, then report findings side by side.

How do I review changes since a specific commit?

Pass any git ref — a commit SHA, tag, branch name, or expression like HEAD~5 — as the fixed point. The skill validates the ref with git rev-parse and confirms the diff is non-empty before starting the review.

What happens if my repo has no documented coding standards?

The Standards axis falls back to a fixed baseline of Fowler code smells from Refactoring chapter 3, such as Duplicated Code, Feature Envy, and Shotgun Surgery. Baseline findings are always labelled judgement calls, and documented repo standards override the baseline.

Where does the code review look for the spec or ticket?

It checks a user-provided path first, then plans/<feature>/spec.md or tickets under plans/<feature>/issues/, then spec files under docs/ or specs/ matching the branch name. If nothing is found, it asks the user, and the Spec axis is skipped when no spec exists.

Why are standards and spec findings reported separately?

A change can pass one axis and fail the other — standards-compliant code can implement the wrong thing, and correct implementations can violate conventions. Keeping the reports separate prevents one axis from masking failures in the other.