code-review

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

Updated Sep 2, 2026
One-click install
npx skills add https://github.com/ZubairImtiaz3/Safar-E-Iman-Portal --skill code-review-zubairimtiaz3
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/ZubairImtiaz3/Safar-E-Iman-Portal/tree/main/.agents/skills/code-review
Command: npx skills add https://github.com/ZubairImtiaz3/Safar-E-Iman-Portal --skill code-review-zubairimtiaz3

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 causes one axis to mask the other, and findings get lost or conflated. ## 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, incorrect implementations) as parallel sub-agents, then reports them side by side. - Fixed-point diffing: Reviews the diff between HEAD and any user-supplied commit, branch, tag, or merge-base using three-dot git diff semantics. - Automatic spec discovery: Locates the originating spec from issue references in commit messages, user-provided paths, or spec 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, with a per-axis summary of the worst finding. ## 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 three-dot git diff. It then runs two parallel sub-agents: one checks documented standards plus a code-smell baseline, the other checks the originating spec.

How does the review find the originating issue or spec?

It looks for issue references in commit messages first, then a user-provided path, 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 if no spec exists.

What code smells does the standards review check for?

The baseline covers Fowler's Refactoring smells including Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Shotgun Surgery, Divergent Change, and others. Documented repo standards always override the baseline, and smells are reported as judgement calls, not hard violations.

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

Yes. Any fixed point works, including HEAD~5, a tag, or an unmerged branch base, since the comparison uses git diff with three-dot merge-base semantics. The review fails early if the ref does not resolve or the diff is empty.

What happens if my repo has no documented coding standards?

The Standards axis still runs using the built-in smell baseline derived from Fowler's Refactoring catalog. Findings are labelled as judgement calls rather than hard violations, and anything tooling already enforces is skipped.