code-review

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

Updated Aug 11, 2026
One-click install
npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill code-review-kunj-sharma03
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/Kunj-Sharma03/agent-contextify/tree/main/skills-main/skills/engineering/code-review
Command: npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill code-review-kunj-sharma03

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a branch or PR requires checking two separate things — whether the code follows the repo's documented standards and whether it actually implements what the issue or spec asked for — and mixing both concerns in one pass causes findings to mask each other. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (documented repo conventions plus a Fowler code-smell baseline) and a Spec review (requirements coverage, scope creep, wrong implementations) as parallel sub-agents, then reports them side by side. - Fixed-point diffing: Reviews changes since any commit, branch, tag, or merge-base using git diff <fixed-point>...HEAD, 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-provided paths, or files under docs/, specs/, or .scratch/. - 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 agent to review the changes on this branch since main against the repo's coding standards and the originating 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 its spec?

Provide a fixed point such as a commit SHA, branch, or tag, and the review compares `git diff <fixed-point>...HEAD` against documented repo standards and the originating spec. Two parallel sub-agents produce separate Standards and Spec reports.

How does the review find the originating issue or spec?

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 nothing is found, it asks the user or reports that no spec is available.

What happens if the 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. Documented repo standards always override this baseline, and smells are reported as judgement calls.

Can I review work-in-progress changes instead of a finished PR?

Yes, any fixed point works, including HEAD~5, a tag, or a branch name. The review validates that the ref resolves and the diff is non-empty before spawning the sub-agents, so bad refs fail early.

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 requirement. Keeping the reports separate prevents one axis from masking the other, so findings are never merged or reranked across axes.