What is the Requesting Code Review skill and what does it do?

This skill documents a workflow for requesting code review by dispatching the superpowers:code-reviewer subagent. It involves obtaining git commit SHAs, filling a code-reviewer.md template with implementation details, and receiving feedback that includes strengths, issues (categorized as Critical, Important, or Minor), and an assessment of readiness to proceed.

When should I use this code review workflow?

Use it mandatorily after each task in subagent-driven development, after completing major features, and before merging to main. It's also valuable when stuck and needing perspective, before refactoring, or after fixing complex bugs. However, do not use it as a substitute for environment-specific validation, testing, or expert review.

What inputs do I need to provide for a code review request?

You need to provide BASE_SHA (the starting commit, obtained via `git rev-parse HEAD~1` or `origin/main`), HEAD_SHA (the ending commit from `git rev-parse HEAD`), WHAT_WAS_IMPLEMENTED (description of what you built), PLAN_OR_REQUIREMENTS (what it should do), and DESCRIPTION (brief summary of changes).

How should I handle the feedback I receive from the code reviewer?

Fix Critical issues immediately before proceeding. Fix Important issues before moving forward. Note Minor issues for later resolution. If you disagree with the reviewer, push back with technical reasoning, but never proceed with unfixed Important issues or ignore Critical feedback.

Skill

Request Code Review Before Merging

Name: Requesting Code Review
Availability: OnlineOnly
Author: Antigravity

A protocol for requesting a code-review subagent after each task, with git SHA setup and a feedback-triage checklist.

Get skill

Works with github

Antigravity

Own this? Claim it

Spark score

out of 100

Updated last month

Version 13.1.0

Add to Favorites

Why it matters

Ensure code quality and catch issues early by automatically requesting code reviews from a specialized subagent before merging to main or completing major features.

Outcomes

What it gets done

Request code review after each task in subagent-driven development.

Initiate review before merging code to the main branch.

Utilize a code-reviewer subagent to identify potential issues.

Act on feedback, prioritizing critical and important issues.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-requesting-code-review | bash

Overview

Requesting Code Review

A protocol for dispatching a code-reviewer subagent after each task or before a merge: capture git SHAs, fill a review template, and triage feedback into Critical, Important, and Minor issues. Use it whenever a task, feature, or fix is complete and needs an independent check, especially in subagent-driven or plan-based development.

What it does

A protocol for dispatching a superpowers:code-reviewer subagent to catch issues before they cascade, built on "review early, review often." Reviews are mandatory after each task in subagent-driven development, after completing a major feature, and before merging to main; optional-but-valuable triggers include being stuck, before refactoring, and after fixing a complex bug. To request one, it captures the base and head git SHAs, dispatches the code-reviewer subagent with a filled template ({WHAT_WAS_IMPLEMENTED}, {PLAN_OR_REQUIREMENTS}, {BASE_SHA}, {HEAD_SHA}, {DESCRIPTION}), and then acts on the returned feedback: fix Critical issues immediately, fix Important issues before proceeding, note Minor issues for later, and push back with reasoning if the reviewer is wrong.

BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
HEAD_SHA=$(git rev-parse HEAD)

It adapts its cadence by workflow: review after every task in subagent-driven development, after every batch of three tasks when executing a plan, and before merge or when stuck in ad hoc development. Its red flags: never skip review because a change "seems simple," never ignore Critical issues, never proceed with unfixed Important issues, and never argue with valid technical feedback - though pushing back on an actually-wrong review with supporting code or tests is expected. A worked example shows this in practice: after completing a task adding verification and repair functions, the dispatched subagent returns strengths (clean architecture, real tests) and issues (an Important missing-progress-indicators gap, a Minor magic-number used for the reporting interval), with an overall "ready to proceed" assessment - and the developer fixes the progress indicators before continuing to the next task.

When to use - and when NOT to

Use it whenever a task, feature, or fix is complete and needs an independent check before proceeding - especially in subagent-driven or plan-executing workflows where issues compound quickly if unreviewed.

Inputs and outputs

Input: a completed unit of work (a task, feature, or bug fix) with its base and head commit SHAs and a description of what was implemented against what was required. Output: a structured review with strengths, issues split into Critical/Important/Minor, and an overall readiness assessment.

Integrations

Dispatches through the Task tool using the superpowers:code-reviewer agent type, filling a template at code-reviewer.md (referenced at requesting-code-review/code-reviewer.md).

Who it's for

Developers and agents running subagent-driven or plan-based development who want a consistent, early review checkpoint - after each task, each three-task batch, or before merge, depending on the workflow - rather than one big review at the end.

FAQ

Common questions

Discussion