Request Code Review Before Merging

Requesting Code Review is a skill for dispatching a code-reviewer subagent, referred to as superpowers:code-reviewer, to catch issues before they cascade. Its core principle is stated in one line: review early, review often. The skill describes when to ask for a review, how to package the request, and how to act on what comes back.

The request has three steps. First, get the git SHAs that bound the change: a base SHA taken from the previous commit or origin/main, and a head SHA taken from the current commit. Second, dispatch the code-reviewer subagent with the Task tool, filling in the template kept in code-reviewer.md. Third, act on the 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.

The template has five placeholders: WHAT_WAS_IMPLEMENTED for what you just built, PLAN_OR_REQUIREMENTS for what it should do, BASE_SHA for the starting commit, HEAD_SHA for the ending commit, and DESCRIPTION for a brief summary.

Review is mandatory after each task in subagent-driven development, after completing a major feature, and before merging to main. It is optional but valuable when you are stuck and want a fresh perspective, before refactoring as a baseline check, and after fixing a complex bug.

The skill lists red flags. Never skip review because the change is simple, ignore Critical issues, proceed with unfixed Important issues, or argue with valid technical feedback. When the reviewer is wrong, push back with technical reasoning, show code or tests that prove it works, and request clarification.

Its limitations section says to use the skill only when the task clearly matches its scope, not to treat the output as a substitute for environment-specific validation, testing or expert review, and to ask for clarification if required inputs or success criteria are missing.

Inputs are the two commit SHAs and the filled template placeholders. The skill shows how to capture them:

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

The output is the subagent's assessment. In the worked example, a reviewer looking at a verification and repair function for a conversation index returns strengths (clean architecture, real tests), one Important issue (missing progress indicators), one Minor issue (a magic number for the reporting interval) and the verdict that it is ready to proceed. The developer then fixes the progress indicators and continues to the next task.

The skill fits three workflows. In subagent-driven development, review after each task so issues do not compound. When executing plans, review after each batch of three tasks, get feedback, apply it and continue. In ad-hoc development, review before merge and whenever you are stuck. It relies on the Task tool and the superpowers:code-reviewer subagent type, with the template stored at requesting-code-review/code-reviewer.md.

It is for developers and coding-agent workflows that build in small tasks and want a consistent review checkpoint at each step, so that problems are found while they are cheap to fix rather than after a merge.