Requesting Code Review

From the author

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

— the description by Jesse Vincent (obra)

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a standardized procedure for triggering an external code review subagent to evaluate code changes. By isolating the review process from the main agent's session, it ensures that the reviewer receives only the necessary context, such as the feature description, requirements, and the specific git commit range. The workflow emphasizes early and frequent reviews to catch issues before they propagate, requiring the user to act on feedback based on severity levels.

What it does

Defines a process for dispatching a dedicated code reviewer subagent.
Provides instructions for identifying the correct git commit range for review.
Outlines a template-based approach to providing context to the reviewer.
Categorizes feedback into Critical, Important, and Minor issues.
Establishes rules for handling reviewer feedback and managing disagreements.
Prevents context window bloat by keeping the review process separate from the main task execution.

When to use it

After completing a specific task within a larger development plan.
Upon finishing the implementation of a major feature.
Immediately before merging code into the main branch.
When seeking a fresh perspective on a complex bug fix.
Before initiating a refactoring process to establish a baseline.

Advantages

Maintains a clean context window for the primary agent.
Ensures objective evaluation of code against requirements.
Reduces the risk of cascading errors by catching issues early.
Provides a clear, actionable path for addressing feedback.
Standardizes the review process across different development tasks.

Usage examples

“I have finished implementing the new authentication module. Please initiate a code review.”: The agent identifies the relevant git SHAs, dispatches the code reviewer subagent with the module's requirements, and waits for the assessment before proceeding.
“The code reviewer flagged an important issue regarding error handling. How should I proceed?”: The agent instructs you to fix the identified issue before continuing to the next task, ensuring the codebase remains stable.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/obra/requesting-code-review/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip requesting-code-review.zip -d .agents/skills

Documentation by Jesse Vincent (obra)

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: git merge-base origin/main HEAD
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 | cut -d' ' -f1)
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

Files

ATTRIBUTION.mdAdded by AutoGineer877 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md2.9 KiB
code-reviewer.md6.3 KiB

SKILL.md