Requesting code review

Skill NafisRayan/100x-Agent-Toolkit/skills/requesting-code-review

A production-grade engineering toolkit for AI-assisted software development. Contains 168 specialized skill workflows (100 core + 68 GSD sub-skills), 142 expert agent personas, 24 design system specifications, 5 reference checklists, 84 slash commands, and 9 MCP server integrations.

Install

npx -y skills add NafisRayan/100x-Agent-Toolkit --skill requesting-code-review

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

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
1 stars1 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

2.7 KB, 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. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.

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:

Use Task tool with general-purpose type, fill 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]

Integration with Workflows

Subagent-Driven Development:

Review after EACH task
Catch issues before they compound
Fix before moving to next task

Executing Plans:

Review after each task or at natural checkpoints
Get feedback, apply, continue

Ad-Hoc Development:

Review before merge
Review when stuck

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: requesting-code-review/code-reviewer.md

Gives 4 of the 12 instructions most code review skills give

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.