code-review

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

1|Updated Apr 25, 2025
One-click install
npx skills add https://github.com/Gabr1elaugus700/WorkaPool --skill code-review-gabr1elaugus700
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/Gabr1elaugus700/WorkaPool/tree/main/.agents/skills/code-review
Command: npx skills add https://github.com/Gabr1elaugus700/WorkaPool --skill code-review-gabr1elaugus700

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 PRD asked for — and mixing both concerns 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 from the originating issue or PRD) 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 issue references in commit messages, a user-supplied path, 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 conventions and code smells, plus a Spec report listing missing requirements and scope creep, each under its own heading. ## 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 two parallel sub-agents: one checks documented standards and code smells, the other checks the originating issue or PRD.

How does the review find the spec or requirements for a change?

It looks for issue references in commit messages first, then a user-supplied path, then PRD files under docs/, specs/, or .scratch/ matching the branch. If no spec exists, the Spec sub-agent is skipped and the report notes that no spec was 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 labelled judgement calls rather than hard violations, and documented repo standards always override the baseline.

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

Yes, any fixed point works — a commit SHA, tag, HEAD~5, or a branch name. 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 — standards-compliant code can implement the wrong thing, and correct implementations can break conventions. Keeping the reports separate prevents one axis from masking failures in the other.