code-review

Reviews completed code changes for red flags, architecture conformance, duplication, and complexity.

1|1|Updated Jun 24, 2026
One-click install
npx skills add https://github.com/growmax/growmax-skills --skill code-review-growmax
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/growmax/growmax-skills/tree/main/gmax/skills/code-review
Command: npx skills add https://github.com/growmax/growmax-skills --skill code-review-growmax

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews are inconsistent and often miss critical issues like secrets, silent fallbacks, or architecture violations while wasting time on style nits. This Skill provides a disciplined senior-engineer review procedure with hard token budgets and a prioritized checklist. ## Core Features & Use Cases - Prioritized review axes: Red flags first (secrets, type-safety escapes, silent fallbacks, hardcoding), then architecture conformance, duplication, and complexity. - Mechanical grep-first workflow: Cheap pattern scans run before expensive file reads, with a hard cap on duplication searches to control token usage. - Structured verdict report: Produces APPROVE / FIX FIRST / BLOCK verdicts with path:line findings, plus drift-pattern candidates for the project's standards. - Use Case: After an agent implements a feature per a plan document, run this review to verify the diff matches the design's boundaries, catch a price ?? 0 silent fallback, and confirm no regression-surface consumers broke. ## Quick Start Ask the AI to review the completed change for the current task using the code-review procedure and report a verdict with findings.

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 code change like a senior engineer?▼

Review in priority order: red flags first (secrets, silent fallbacks, type-safety escapes), then architecture conformance, duplication, and complexity. Read the plan and full changed files, not just the diff, and report findings with path:line locations.

How to review large diffs without running out of context?▼

Run cheap mechanical greps before deep file reads, cap duplication searches at about 10 purpose-queries, and review phase by phase in plan order. State which phases you covered rather than attempting a thin review of everything.

What counts as a blocking issue in a code review?▼

Blocking issues include secrets in the diff, broken data integrity, invented layers or patterns, violated design invariants, and broken regression-surface consumers. Hardcoded literals and missing edge states are FIX FIRST, not blockers.

When should duplicated code be flagged in review?▼

Flag a clone only when a bug fix would need applying in both places. Similar-looking code in unrelated features is not duplication, and a shared abstraction with a single caller should be flagged as premature extraction.

Should a code reviewer fix the issues it finds?▼

No. This review procedure is report-only: every finding gets a path:line location and the smallest suggested fix, but the reviewer never edits code. Formatting and personal style are left to the linter.