code-review

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

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/falentio/cimi --skill code-review-falentio
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/falentio/cimi/tree/main/.agents/skills/skills/code-review
Command: npx skills add https://github.com/falentio/cimi --skill code-review-falentio

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. Mixing both in one review lets one axis mask the other. ## Core Features & Use Cases - Two-axis review: Runs a Standards review and a Spec review as parallel sub-agents so their contexts stay separate, then reports findings side by side. - Fowler smell baseline: Applies a fixed set of code smells from Refactoring (Duplicated Code, Feature Envy, Shotgun Surgery, and more) even when the repo documents no standards, with documented repo rules always overriding the baseline. - Spec traceability: Locates the originating spec from issue references in commit messages, a user-supplied path, or files under docs/, specs/, or .scratch/, and flags missing requirements, scope creep, and incorrect implementations. - Use Case: Before merging a feature branch, ask for a review since main and receive separate Standards and Spec reports, each with quoted evidence and a per-axis summary. ## Quick Start Ask the assistant to review the changes since main using the code-review skill, and point it at the issue or spec file if one exists.

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 it against HEAD using a three-dot merge-base comparison. It then runs a Standards review and a Spec review as parallel sub-agents and reports both sets of findings side by side.

What happens if my repo has no documented coding standards?

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

How does the review find the originating spec or issue?

It looks for issue references in commit messages first, then a path you pass as an argument, then spec files under docs/, specs/, or .scratch/ matching the branch or feature. If nothing is found, it asks you, and the Spec axis is skipped when no spec exists.

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

Yes. Any fixed point that git rev-parse can resolve works, including HEAD~5, a tag, or a branch name. The skill verifies the ref resolves and the diff is non-empty before spawning the review sub-agents.

Why are standards and spec findings reported separately?

A change can follow every standard but implement the wrong thing, or implement the spec correctly while breaking project conventions. Keeping the axes separate prevents one from masking the other, so findings are never merged or reranked across axes.