code-review

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

Updated Sep 21, 2026
One-click install
npx skills add https://github.com/maxentr/la-cuisine-de-mm --skill code-review-maxentr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/maxentr/la-cuisine-de-mm/tree/main/.agents/skills/code-review
Command: npx skills add https://github.com/maxentr/la-cuisine-de-mm --skill code-review-maxentr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a branch or PR requires checking two separate things at once: whether the code follows the repo's documented standards, and whether it actually implements what the originating issue or spec asked for. Doing both in one pass lets one axis mask the other, so problems slip through. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (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 the diff between HEAD and any commit, branch, tag, or merge-base the user supplies, validating the ref and diff before spawning reviewers. - 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 citing the violated rule or spec line. ## 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 a git branch against coding standards and its spec?

Provide a fixed point such as a commit SHA, branch, tag, or main, and the skill diffs it against HEAD using a three-dot merge-base comparison. It then runs Standards and Spec reviews as parallel sub-agents and reports both sets of findings separately.

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

It first looks for issue references in commit messages like #123 or Closes #45 and fetches them via the configured issue tracker workflow. If none exist, it checks a user-provided path, then spec files under docs/, specs/, or .scratch/ matching the branch or feature.

What happens if a repo has no documented coding standards?

The Standards axis falls back to a built-in baseline of Fowler code smells from Refactoring chapter 3, such as Duplicated Code, Feature Envy, and Shotgun Surgery. These baseline findings are always reported as judgement calls, never hard violations.

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

The review operates on git diffs between a fixed point and HEAD, so changes must be committed to appear in the diff. Uncommitted working-tree changes are not covered by the git diff <fixed-point>...HEAD comparison.

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

A change can pass one axis and fail the other, such as clean code implementing the wrong thing. Keeping the reports separate under distinct headings prevents one axis from masking failures in the other and avoids reranking across axes.