code-review

Reviews committed, pull-request, or working-tree changes against repository standards and the originating spec.

2|Updated Sep 14, 2026
One-click install
npx skills add https://github.com/kwanpham2195/agent-stuff --skill code-review-kwanpham2195
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/kwanpham2195/agent-stuff/tree/main/skills/workflow/code-review
Command: npx skills add https://github.com/kwanpham2195/agent-stuff --skill code-review-kwanpham2195

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two different questions: does the code follow the project's conventions, and does it actually implement what was asked? This Skill separates those concerns into two independent review axes so a failure in one cannot be masked by a pass in the other, and so findings are grounded in cited standards and spec lines rather than vague opinion. ## Core Features & Use Cases - Two-axis review: Runs a Standards axis (documented repo conventions plus a fixed Fowler code-smell baseline) and a Spec axis (requirements coverage, scope creep, incorrect implementations) as parallel sub-agents or sequentially. - Flexible change-set selection: Reviews pull requests, committed ranges (three-dot merge-base or exact two-dot diffs), and WIP working-tree changes including staged, unstaged, and untracked files. - Automatic spec and standards discovery: Locates the originating issue, PRD, or spec file and the repo's coding standards documents, falling back to a general baseline when none exist. - Use Case: Before merging a feature branch, ask for a review against the original issue. You receive a ## Standards report citing violated conventions and smells, and a ## Spec report quoting unmet requirements, plus a one-line summary per axis. ## Quick Start Review this branch against the original issue and the repository standards, and report findings under separate Standards and Spec headings without editing any files.

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 pull request against coding standards and the original spec?▼

Point the review at the pull request; its base is resolved automatically. The Standards axis checks the diff against documented repo conventions and a code-smell baseline, while the Spec axis compares the diff against the originating issue or PRD, reporting each separately.

How do I review uncommitted working-tree changes before committing?▼

Request a WIP review. The process captures the committed range when a base exists, then inspects unstaged changes with git diff, staged changes with git diff --cached, and untracked files via git ls-files, including all of them in the review scope.

What is the difference between two-dot and three-dot git diff in reviews?▼

The default committed-range review uses three-dot syntax (git diff <ref>...HEAD), comparing from the merge-base. If you request an exact commit comparison or supply a two-dot range, that exact range is used instead of silently substituting a merge-base comparison.

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

The process searches commit messages for issue references, checks user-supplied paths, and looks for PRD files under docs/, specs/, or .scratch/. If none is found and you confirm none exists, the Spec axis is skipped and the final report notes that no spec was available.

Which 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 reported as a labelled judgement call, and documented repo standards always override the baseline.

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

A change can pass one axis and fail the other: standards-compliant code may implement the wrong thing, and a correct implementation may violate conventions. Keeping the reports separate prevents one axis from masking failures in the other and avoids cross-axis reranking.