Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
pixel-process-ug avatar

Code Review

  • 69 installs
  • 1 repo stars
  • Updated March 16, 2026
  • pixel-process-ug/superkit-agents

Helps with ai & agent building tasks.

About

code-review is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.

  • code-review
  • AI & Agent Building
  • AI-coding skill

Code Review by the numbers

  • 69 all-time installs (skills.sh)
  • +2 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #5,786 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill code-review

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs69
repo stars1
Last updatedMarch 16, 2026
Repositorypixel-process-ug/superkit-agents

What it does

Helps with ai & agent building tasks.

Files

SKILL.mdMarkdownGitHub ↗

Code Review

Overview

Comprehensive code review against the original plan, coding standards, and learned project patterns. This skill dispatches a dedicated code-reviewer agent for thorough analysis, ensuring every change is evidence-based, plan-aligned, and convention-aware before it reaches the main branch.

Announce at start: "I'm using the code-review skill to review the implementation."

---

Phase 1: Gather Context

Goal: Identify what changed, what the plan required, and what conventions apply.

Actions

1. Retrieve the changes to review:

git diff HEAD~N..HEAD          # or specific commit range
git log --oneline HEAD~N..HEAD # what was done

2. Locate the plan document:

ls docs/plans/*.md | tail -1

3. Load project conventions from memory/learned-patterns.md

4. Identify:

  • What files were changed
  • What the plan/spec required
  • What conventions apply

STOP — Do NOT proceed to Phase 2 until:

  • [ ] All changed files are identified
  • [ ] The plan or spec requirements are loaded
  • [ ] Relevant conventions from memory are loaded
  • [ ] You can state what was supposed to be built

---

Phase 2: Dispatch Code Reviewer

Goal: Send structured review request to the code-reviewer agent.

Review Prompt Template

Review the following changes against:
1. Plan: [plan document or requirements]
2. Conventions: [learned patterns from memory]
3. Standards: [CLAUDE.md rules]

Changes:
[git diff output or file list]

Check for:
- Plan alignment (did we build what was specified?)
- Code quality (DRY, YAGNI, naming, structure)
- Error handling (edge cases, failure modes)
- Security (injection, XSS, auth issues)
- Test coverage (are changes tested?)
- Performance (obvious bottlenecks)
- Documentation (are public APIs documented?)

STOP — Do NOT proceed to Phase 3 until:

  • [ ] Review request has been dispatched
  • [ ] Reviewer agent has returned findings

---

Phase 3: Categorize and Resolve Issues

Goal: Classify findings and fix all Critical issues.

Issue Categorization Table

CategoryDefinitionAction Required
CriticalBugs, security issues, data loss risk, plan violationsMust fix before merge
ImportantCode quality, missing tests, convention violationsShould fix before merge
SuggestionsStyle, naming, minor improvementsNice to have, fix if time allows

Fix Loop

For Critical and Important issues: 1. Fix the issue 2. Run tests to verify the fix 3. Re-dispatch code-reviewer agent for the specific fix 4. Repeat until no Critical issues remain

STOP — Do NOT proceed to Phase 4 until:

  • [ ] All Critical issues are resolved
  • [ ] All Important issues are resolved or explicitly deferred with justification
  • [ ] Test suite passes after all fixes

---

Phase 4: Self-Learning Integration

Goal: Persist patterns discovered during review for future sessions.

Actions

1. If new patterns were identified, update memory/learned-patterns.md 2. If a common mistake was found, note it for future reference 3. If the plan needed adjustment, update memory/decisions-log.md

---

Review Output Format

## Code Review Summary

**Scope:** [files/components reviewed]
**Plan alignment:** [aligned / minor deviations / major deviations]

### Critical Issues (N)
1. **[Issue title]** — `file:line`
   Problem: [description]
   Fix: [specific recommendation]

### Important Issues (N)
1. **[Issue title]** — `file:line`
   Problem: [description]
   Fix: [specific recommendation]

### Suggestions (N)
1. **[Suggestion]** — `file:line`

### What Was Done Well
- [Positive observations]

---

Decision Table: Review Depth

Change TypeReview DepthReviewer
New feature (>100 lines)Full review: plan alignment + quality + security + testscode-reviewer agent
Bug fix (<50 lines)Focused review: regression test + root cause + fix correctnesscode-reviewer agent
Refactor (no behavior change)Behavior preservation: all tests pass + no regressionscode-reviewer agent
Config/infra changeSecurity + correctness: no secrets exposed, valid syntaxcode-reviewer agent
Documentation onlyAccuracy + completeness: matches current code behaviorInline review

---

Anti-Patterns / Common Mistakes

Anti-PatternWhy It Is WrongCorrect Approach
Skipping review for "small fixes"Small changes cause production outagesReview everything
Reviewing without the planCannot verify correctness without requirementsAlways load the plan first
Fixing issues without re-running testsFixes can introduce new bugsRun full test suite after every fix
Generic feedback ("looks good")Not actionable, misses real issuesCite specific code lines with fix recommendations
Reviewing your own code aloneAuthor blindness misses defectsAlways dispatch code-reviewer agent
Deferring Critical issuesCritical issues become production incidentsMust fix before merge, no exceptions

---

Rationalizations — STOP If You Think These

ExcuseReality
"It's just a typo fix"Typo fixes can break APIs. Review it.
"I'm confident in this code"Confidence does not equal correctness. Review it.
"The tests pass"Tests can miss bugs. Review it.
"It's just styling/formatting"Style changes can introduce bugs. Review it.
"Nobody will notice"That is exactly when bugs ship. Review it.
"I'll review it later"Later never comes. Review it now.
"The deadline is tight"Shipping bugs costs more than reviewing. Review it.

---

Subagent Dispatch Opportunities

Task PatternDispatch ToWhen
Reviewing multiple independent files/modulesAgent tool with subagent_type="Explore"When review scope spans multiple unrelated modules
Security-focused review passAgent tool invoking security-review skillWhen changes touch auth, input handling, or external APIs
Performance impact assessmentAgent tool invoking performance-optimization skillWhen changes affect hot paths or data-heavy operations

Follow the dispatching-parallel-agents skill protocol when dispatching.

---

Integration Points

SkillRelationship
planningReview checks implementation against the approved plan
test-driven-developmentReview verifies test coverage and TDD compliance
verification-before-completionReview is a prerequisite for verification
self-learningReview findings feed into learned patterns
acceptance-testingReview checks that acceptance tests exist for all criteria
systematic-debuggingIf review reveals a bug, switch to debugging skill
security-reviewSecurity findings during review trigger deeper security analysis

---

Iron Law

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: NO MERGE WITHOUT REVIEW                            │
│                                                                 │
│  Every change gets reviewed. No exceptions for "small fixes"   │
│  or "obvious changes." If you are about to merge without       │
│  review, STOP immediately.                                     │
└─────────────────────────────────────────────────────────────────┘

---

Skill Type

RIGID — The four-phase process is mandatory. Every change must be reviewed by the code-reviewer agent. No merge without review. No exceptions.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.