Requesting code review

Skill h3y6e/agent-skills/.vendor/skills/requesting-code-review

my agent skills

Install

npx -y skills add h3y6e/agent-skills --skill requesting-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

SKILL.md

3.1 KB, 653 tokens by cl100k_base, as published. Nobody here has run it

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

Placeholders:

{DESCRIPTION} - Brief summary of what you built
{PLAN_OR_REQUIREMENTS} - 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

Gives 4 of the 12 instructions most code review skills give in 653 tokens

Counted across 610 of the 674 authors here whose files we hold, read 2026-08-06

push back with technical reasoning if wronghere, and in 60 of 610, across 24 files
ask for clarification on unclear itemsin 51 of 610, across 16 files
fix critical issues immediatelyhere, and in 45 of 610, across 29 files
implement one item at a timein 45 of 610, across 11 files
group findings by severityin 44 of 610, across 43 files
verify feedback against the codebasein 42 of 610, across 8 files
dispatch a code reviewer subagenthere, and in 39 of 610, across 23 files
fix important issues before proceedinghere, and in 37 of 610, across 22 files
test each fix individuallyin 35 of 610, across 7 files
reply in github comment threadsin 33 of 610, across 5 files
check for security vulnerabilitiesin 31 of 610, across 27 files
factualize corrections without over-explainingin 30 of 610, across 2 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.