home / skills / nickcrew / claude-cortex / requesting-code-review

requesting-code-review skill

/skills/requesting-code-review

This skill streamlines code-review requests by dispatching a code-reviewer subagent to validate implementations against plan and requirements.

This is most likely a fork of the requesting-code-review skill from mosif16
npx playbooks add skill nickcrew/claude-cortex --skill requesting-code-review

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
2.8 KB
---
name: requesting-code-review
description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches superpowers:code-reviewer subagent to review implementation against plan or requirements before proceeding
---

# Requesting Code Review

Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.

**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:**
```bash
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 superpowers:code-reviewer type, fill template at `code-reviewer.md`

**Placeholders:**
- `{WHAT_WAS_IMPLEMENTED}` - What you just built
- `{PLAN_OR_REQUIREMENTS}` - What it should do
- `{BASE_SHA}` - Starting commit
- `{HEAD_SHA}` - Ending commit
- `{DESCRIPTION}` - Brief summary

**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 superpowers:code-reviewer subagent]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[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 batch (3 tasks)
- 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

Overview

This skill dispatches a code-reviewer subagent to verify an implementation against the intended plan or requirements before you continue. It enforces the core principle: review early, review often. Use it to catch issues quickly and prevent problems from compounding during subagent-driven or ad-hoc development.

How this skill works

You provide the review subagent with the commit range (BASE_SHA and HEAD_SHA), a short description of what was implemented, and the plan or requirements it should satisfy. The subagent analyzes diffs, tests, architecture, and coding patterns, then returns strengths, categorized issues (Critical, Important, Minor), and an overall assessment. Act on feedback by fixing high-severity items, noting minor items, or disputing incorrect findings with evidence.

When to use it

  • After completing each task in subagent-driven development (mandatory)
  • After finishing a major feature or batch of tasks
  • Before merging changes to main or release branches
  • When you’re stuck and need a fresh perspective
  • Before large refactors to establish a baseline

Best practices

  • Always include BASE_SHA and HEAD_SHA so the reviewer sees exact diffs
  • Provide a concise PLAN_OR_REQUIREMENTS block that explains expected behavior
  • Treat Critical issues as blockers and Important issues as pre-merge fixes
  • Record reviewer feedback and link changes back to it for traceability
  • If you disagree, respond with tests, benchmarks, or examples that demonstrate correctness

Example use cases

  • After Task N in a multi-step implementation to ensure the change fits the plan
  • Before merging a feature branch that touches core modules or APIs
  • After fixing a subtle production bug to confirm no regressions were introduced
  • Prior to a refactor to capture current behavior and surface edge cases
  • When delivering a contract feature that must meet explicit requirements

FAQ

What inputs are required for a meaningful review?

Provide BASE_SHA, HEAD_SHA, a concise description of what was implemented, and the plan or requirements the change should meet.

How should I handle reviewer disagreements?

Respond with technical reasoning, tests, or demos that prove correctness. If still unresolved, iterate with the reviewer or escalate to a peer for arbitration.