code-review

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

Updated May 9, 2024
One-click install
npx skills add https://github.com/AceCodePt/dotfiles --skill code-review-acecodept
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/AceCodePt/dotfiles/tree/main/.config/opencode/skills/code-review
Command: npx skills add https://github.com/AceCodePt/dotfiles --skill code-review-acecodept

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 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 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: Compares HEAD against 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 tasks/<name>/task.md, a user-supplied path, or docs/specs directories, and gracefully reports when no spec exists. - Use Case: Before merging a feature branch, ask for a review since main and receive separate Standards and Spec reports with cited violations, quoted spec lines, and a per-axis summary. ## 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 Standards and Spec reviews as parallel sub-agents and reports both sets of findings side by side.

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

It looks first for tasks/<name>/task.md matching the branch name, then a path the user passes, then spec files under docs/, specs/, or .scratch/. If none is found it asks the user, and if there is no spec the Spec axis reports that none is available.

What happens if the repo has no documented coding standards?▼

The Standards axis falls back to a built-in baseline of Fowler code smells such as Duplicated Code, Feature Envy, and Shotgun Surgery. These are reported as judgement calls, never hard violations, and any documented repo standard overrides the baseline.

Can I review work-in-progress changes instead of a finished PR?▼

Yes, any fixed point works, including HEAD~5, a tag, or an arbitrary commit. The skill validates the ref with git rev-parse and confirms the diff is non-empty before spawning the review sub-agents.

Why are standards and spec findings reported separately?▼

A change can pass one axis and fail the other, such as clean code implementing the wrong thing. Keeping the reports separate prevents one axis from masking the other, so findings are never merged or reranked across axes.