code-review

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

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/kashman001/ai-workspace-template --skill code-review-kashman001
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/kashman001/ai-workspace-template/tree/main/skills/code-review
Command: npx skills add https://github.com/kashman001/ai-workspace-template --skill code-review-kashman001

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — does the code follow the repo's standards, and does it actually implement what was asked — letting one axis mask failures in the other. This Skill separates them into independent parallel reviews so neither hides the other's findings. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (repo conventions 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. - 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. - Spec discovery: Locates the originating spec from issue references in commit messages, a user-supplied path, 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 possible smells, plus a Spec report quoting unmet or over-built requirements. ## Quick Start Ask the assistant to review the changes on this branch since main using the code-review skill.

Frequently Asked Questions about code-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review all changes on a branch since main?▼

Provide the fixed point (e.g., main) and the skill runs git diff main...HEAD using the three-dot merge-base comparison. It then spawns parallel Standards and Spec sub-agents and aggregates their findings under separate headings.

How does the spec review find the originating issue or spec?▼

It looks for issue references in commit messages first, then a user-supplied path, then spec files under docs/, specs/, or .scratch/ matching the branch or feature. If nothing is found, it asks the user, and the Spec axis reports no spec available.

What coding standards does the review check against?▼

It uses whatever the repo documents, such as CODING_STANDARDS.md or CONTRIBUTING.md, plus a fixed baseline of Fowler code smells like Duplicated Code, Feature Envy, and Shotgun Surgery. Documented repo standards always override the baseline.

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

The review is built around git diff against a fixed point such as a commit, branch, tag, or HEAD~N. Uncommitted changes appear in the diff relative to that ref, so they are included as long as the diff is non-empty.

Why does the review report Standards and Spec separately?▼

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