Dispatch code review subagents with focused context to catch issues before they compound.
Integrates with subagent-driven development workflows, triggering review after each task or before merging to main Provides code-reviewer subagent with precise git SHAs, implementation details, and requirements, keeping reviewer focused on work product rather than session history Categorizes feedback into Critical (fix immediately), Important (fix before proceeding), and Minor (note for later) severity levels Includes template-based dispatch mechanism using Task tool with placeholders for implementation summary, requirements, commit range, and description
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
This skill provides a structured way to request and process code reviews using a subagent. It retrieves git diffs and commit information to present changes for assessment. While it uses dynamic command assembly and placeholder interpolation which are standard for such tools, no malicious behaviors, data exfiltration, or safety bypasses were found.
snykLOW
Analyzed May 5, 2026
No issues detected.
socketScore 0.9000 · 0 alerts
Analyzed May 5, 2026
license1
maintenance1
quality0.9
supply chain1
vulnerability1
0 alerts
Related skills
Skills linked from this page on skills.sh — browsable neighbors in the catalog.
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Claude CodeNot declared
CursorNot declared
CodexNot declared
GitHub CopilotNot declared
WindsurfNot declared
Gemini CLINot declared
ClineNot declared
OpenCodeNot declared
Repository health
Stars283.3K
LicenseLICENSE
Default branchmain
Open issues125
Status
Active
Package contents
Files included with this skill beyond the listing page.
skill mdSKILL.md2,956 B
docsSUMMARY.md137 B
History
First seen on skills.sh
First recorded snapshot · 223,100 installs
SKILL.md
Requesting Code Review
Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.
Core principle: Review early, review often.
When to Request Review
Mandatory:
After each task in subagent-driven development
After completing major feature
Before merge to main
Optional but valuable:
When stuck (fresh perspective)
Before refactoring (baseline check)
After fixing complex bug
How to Request
1. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. Dispatch code reviewer subagent:
Dispatch a general-purpose subagent, filling the template at [code-reviewer.md](code-reviewer.md)
Placeholders:
{DESCRIPTION} - Brief summary of what you built
{PLANORREQUIREMENTS} - What it should do
{BASE_SHA} - Starting commit
{HEAD_SHA} - Ending commit
3. Act on feedback:
Fix Critical issues immediately
Fix Important issues before proceeding
Note Minor issues for later
Push back if reviewer is wrong (with reasoning)
Example
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[Dispatch code reviewer subagent]
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
[Subagent returns]:
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed
You: [Fix progress indicators]
[Continue to Task 3]
Common Rationalizations
Excuse
Reality
"I'll just review the diff myself instead of dispatching a reviewer"
You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you.
"The reviewer needs my whole session history to understand the change"
Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process.
Red Flags
Never:
Skip review because "it's simple"
Ignore Critical issues
Proceed with unfixed Important issues
Argue with valid technical feedback
If reviewer wrong:
Push back with technical reasoning
Show code/tests that prove it works
Request clarification
See template at: [code-reviewer.md](code-reviewer.md)