code-review

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

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/mikalv/pi-extensions --skill code-review-mikalv
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/mikalv/pi-extensions/tree/main/packages/pi-atelier/.agents/skills/code-review
Command: npx skills add https://github.com/mikalv/pi-extensions --skill code-review-mikalv

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — does the code follow the project's standards, and does it actually implement what was asked for — letting one axis mask failures in the other. This Skill separates them into independent parallel reviews so neither hides the other. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (repo-documented conventions plus a fixed Fowler code-smell baseline) and a Spec review (against the originating issue, PRD, or spec file) as parallel sub-agents. - Fixed-point diffing: Reviews changes since any commit, branch, tag, or merge-base using three-dot git diff, with early validation of the ref and diff. - Spec discovery: Automatically locates the 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 side-by-side Standards and Spec reports with per-file findings and a one-line summary per axis. ## Quick Start Ask the agent 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 changes since a specific commit or branch?▼

Provide any fixed point — a commit SHA, branch name, tag, or expression like HEAD~5 — and the review compares it against HEAD using a three-dot git diff from the merge-base. If you don't specify one, the skill asks for it before proceeding.

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

It looks first for issue references in commit messages (like #123 or Closes #45), then a path you pass as an argument, then PRD files under docs/, specs/, or .scratch/ matching the branch. If nothing is found, it asks you, and the Spec axis is skipped if no spec exists.

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, and anything tooling already enforces is skipped.

Why are standards and spec reviewed separately instead of combined?▼

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 conventions. Keeping the reports separate prevents one axis from masking failures in the other.

What happens if the fixed point is invalid or the diff is empty?▼

The skill validates the ref with git rev-parse and confirms the diff is non-empty before spawning any sub-agents. A bad ref or empty diff fails immediately at that step rather than inside the parallel review agents.