code-review

Reviews diffs, PRs, and commits with evidence-backed findings across critical and informational categories.

Updated Mar 24, 2026
One-click install
npx skills add https://github.com/hanh-nd/agent-kit --skill code-review-hanh-nd
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/hanh-nd/agent-kit/tree/main/plugins/agent-kit/.gemini/skills/code-review
Command: npx skills add https://github.com/hanh-nd/agent-kit --skill code-review-hanh-nd

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often miss regressions hiding in unchanged callers, skip entire risk categories, or rubber-stamp changes without evidence. This Skill enforces a rigorous, four-phase review process that produces auditable, evidence-backed verdicts instead of superficial approvals. ## Core Features & Use Cases - Four-phase review workflow: Names the semantic review unit, builds context from tests and consumers, sweeps critical and informational categories, then self-critiques to catch missed issues. - Evidence-backed findings: Every finding carries a file:line anchor with reasoning and a concrete fix, and every checked category produces a clearance line for auditability. - Structured verdict report: Outputs BLOCKERS, CONCERNS, NITPICKS, and coverage notes with a clear APPROVE, REQUEST CHANGES, or COMMENT ONLY verdict. - Use Case: A reviewer receives a large PR mixing a new API route with refactoring. The Skill detects scope drift, checks all consumers of changed contracts outside the diff, flags a missing enum consumer as a BLOCKER, and recommends splitting the unreviewable parts. ## Quick Start Ask the AI to review the current pull request diff against the stated ticket intent and produce a verdict report with blockers and coverage.

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 hidden regressions?▼

Review the feature as a semantic unit rather than file by file, then search the codebase for consumers of every changed contract such as signatures, enums, and API schemas. A consumer outside the diff that was not updated is a blocker, since most regressions live in callers assuming old behavior.

What should a code review checklist cover before merging?▼

Cover injection and untrusted input, concurrency and atomicity, trust boundaries, state completeness, destructive operations, and hidden error swallowing as critical categories. Then check logic correctness, side effects, duplicated code, magic values, dead code, test parity, performance, and naming as informational concerns.

Can this review skill handle any programming language?▼

Yes, the review process is language- and domain-agnostic. It operates on the diff, stated intent, and codebase context, applying semantic categories like concurrency, trust boundaries, and state completeness that apply across languages and frameworks.

When should a pull request be split instead of reviewed?▼

Split when feature work is mixed with broad refactoring, unrelated ownership areas, or a size that makes coverage performative. Large deletions, generated files, and mechanical refactors remain reviewable when intent and verification are clear.

What happens when a PR has no description or ticket?▼

The review proceeds on technical semantics only, with a warning prepended to the report that no stated intent exists. Scope drift cannot be assessed without intent, so that dimension of the review is explicitly degraded rather than silently skipped.