review

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

Updated Jul 4, 2024
One-click install
npx skills add https://github.com/hareki/dotfiles --skill review-hareki
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: review
Source: https://github.com/hareki/dotfiles/tree/main/agents/.agents/skills/review
Command: npx skills add https://github.com/hareki/dotfiles --skill review-hareki

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — does the code follow project conventions, and does it actually implement what was asked — letting one axis mask failures in the other. This Skill separates those concerns into independent parallel reviews so neither hides the other's findings. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (against documented coding standards like CODING_STANDARDS.md or CONTRIBUTING.md) and a Spec review (against the originating issue, PRD, or spec file) as parallel sub-agents. - Fixed-point diffing: Compares HEAD against any commit, branch, tag, or merge-base using three-dot git diff, 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 PRD 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 rules and a Spec report listing missing requirements, scope creep, and incorrect implementations, side by side. ## Quick Start Ask the assistant to review the changes on this branch since main using the review skill.

Frequently Asked Questions about 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 runs two parallel sub-agents: one checks the diff against documented coding standards, the other checks it against the originating issue or PRD. Results are reported under separate Standards and Spec headings.

How does the review find the spec for a branch?▼

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

What git diff does the review use for comparing changes?▼

It uses a three-dot diff, git diff <fixed-point>...HEAD, so the comparison is against the merge-base rather than the tip of the fixed point. It also validates the ref with git rev-parse and fails early on empty diffs.

Why are standards and spec reviews 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 the other's findings.

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

The review fails early before spawning any sub-agents. It confirms the fixed point resolves via git rev-parse and that the diff is non-empty, so bad refs or empty diffs never reach the parallel review agents.