code-review

Review branches, pull requests, and working changes against requested behavior with evidence-backed findings.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss the actual scope of changes, rely on speculation, or produce vague style complaints. This Skill enforces a disciplined review process that pins the review scope, verifies each finding in current code, and ranks defects by impact. ## Core Features & Use Cases - Scope Pinning: Determines the correct diff base from the merge-base, PR metadata, or working tree state, including staged, unstaged, and untracked files. - Evidence-Based Findings: Requires each finding to identify the trigger, affected behavior, precise location, and consequence, verified in current code before reporting. - Ranked Reporting: Separates correctness defects from validation gaps and conformance uncertainty, and explicitly reports when no findings are supported. - Use Case: Before merging a pull request, run this Skill to compare the branch against its merge-base, check callers and tests for regressions, and receive a ranked list of verified defects with file locations. ## Quick Start Review the current branch against main and report any verified defects with their locations and impact.

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 pull request for correctness defects?

Pin the review scope using the PR's merge-base, read the originating request or spec, then inspect changed behavior, callers, error handling, and tests. Verify each finding in the current code and rank results by impact before reporting.

How to review uncommitted working tree changes in git?

Include staged, unstaged, and untracked files in the review scope rather than relying on the committed diff. An empty committed diff does not mean the working tree is clean, so inspect all change states explicitly.

What should a code review check beyond style?

Focus on missing or incorrect requested behavior, regressions in callers and state transitions, authorization and validation risks, data-loss exposure, and whether tests exercise the actual changed behavior. Skip formatting already enforced by tooling.

Can a code review proceed without a specification?

Yes, a missing spec limits the conformance assessment but does not block reviewing observable defects. The review should state the limitation and focus on verifiable correctness, regression, and security findings.

When should code review findings not be reported?

Omit speculative style complaints, unrelated refactors, and anything not verified in the current code. Label uncertainty explicitly, and report no findings when none are supported, along with the scope and checks performed.