code-review

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

1|Updated Jul 2, 2026
One-click install
npx skills add https://github.com/filippolmt/skills --skill code-review-filippolmt
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/filippolmt/skills/tree/main/skills/code-review
Command: npx skills add https://github.com/filippolmt/skills --skill code-review-filippolmt

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing a branch or PR requires checking two separate things — whether the code follows the repo's documented standards and whether it actually implements what the issue or spec asked for — and mixing both in one pass lets one axis mask failures in the other. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (documented repo standards plus a fixed baseline of Fowler code smells) and a Spec review (requirements coverage, scope creep, incorrect implementations) as parallel sub-agents, then reports them side by side without merging or reranking. - Fixed-point diffing: Reviews the changes since any commit, branch, tag, or merge-base the user supplies, validating the ref and diff before spawning agents. - Spec discovery: Locates the originating spec from issue references in commit messages, a user-provided path, 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 branch against coding standards and its spec?

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

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

It looks for issue references in commit messages first, then a path passed by the user, 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 is skipped when no spec exists.

What happens if the repo has no documented coding standards?

The Standards axis still applies a fixed baseline of Fowler code smells such as Duplicated Code, Feature Envy, and Shotgun Surgery. These baseline findings are always reported as judgement calls, and any documented repo standard overrides the baseline.

Why does the review fail before the sub-agents run?

The skill validates the fixed point with git rev-parse and checks that the diff is non-empty before spawning sub-agents. An unresolvable ref or empty diff fails fast at that step rather than inside the parallel agents.

When should I not use this two-axis review approach?

It is designed for reviewing a diff against a fixed point, so it does not fit whole-codebase audits or reviews with no spec and no standards context. For those, a general architecture or linting review is more appropriate.