# Requesting Code Review

> Prepare repo-local review requests and required context for the current workflow. Use when completing tasks, implementing major features, or before merging and the work should enter `ac-review`.

- Skill: `shengwang-community/requesting-code-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add shengwang-community/requesting-code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shengwang-community/requesting-code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: shengwang-community (https://skillmd.com/u/shengwang-community)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shengwang-community/requesting-code-review

---


# Requesting Code Review

Prepare a repo-local review request that feeds the current `ac-review` path with the right Contract, Evidence, and Gaps. In this repository, review should stay inside the existing workflow instead of dispatching external reviewer subagents that do not write back to the active task state file.

**Core principle:** Review early, review often.

## When to Request Review

**Mandatory:**
- After completing a major feature or complex bugfix that should enter reviewer route
- Before merge / handoff when the current work needs repo-local acceptance
- After docs / skills / workflow rule changes that need consistency validation

**Optional but valuable:**
- When stuck (fresh perspective)
- Before refactoring (baseline check)
- After fixing complex bug

## How to Request

**1. Refresh repo-local state first**

- Ensure the active task state file reflects the current Contract, latest `Evidence`, and current `Gaps`
- If the task is already on a reviewer route, keep using the current workflow rather than opening a separate review path

**2. Prepare the review brief**

Use the template at `code-reviewer.md` as a structured review brief for the current repo-local reviewer flow.

**Placeholders:**
- `{WHAT_WAS_IMPLEMENTED}` - What you just built
- `{PLAN_OR_REQUIREMENTS}` - What it should do
- `{CHANGED_FILES}` - Files or modules touched in this round
- `{CHECKS_RUN}` - Commands, consistency checks, or manual paths actually run
- `{EVIDENCE_SUMMARY}` - Most relevant fresh evidence
- `{GAP_SUMMARY}` - Remaining risks or unverified areas
- `{BASE_SHA}` - Starting commit
- `{HEAD_SHA}` - Ending commit
- `{DESCRIPTION}` - Brief summary

**3. Route into review**

- If current route is `single + reviewer` or `planner -> executor -> reviewer`, hand off to `ac-review`
- If review is being requested ad hoc, return to `ac-workflow` / current workflow path and request review there
- Do not dispatch external `Task tool` / `superpowers:code-reviewer` flow unless the active repo workflow explicitly supports it

**4. 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)

[Prepare repo-local review brief]
  WHAT_WAS_IMPLEMENTED: Login state handling and token refresh fallback
  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/android-auth-flow.md
  CHANGED_FILES: feature/login/LoginViewModel.kt, data/auth/AuthRepository.kt, feature/login/LoginViewModelTest.kt
  CHECKS_RUN: ./gradlew test
  EVIDENCE_SUMMARY: Added tests for login success, refresh fallback, and expired token path
  GAP_SUMMARY: No low-memory process death validation yet
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added login state management and token refresh fallback for expired sessions

[ac-review returns]:
  Strengths: Clear state ownership, focused tests
  Issues:
    Important: Loading state not cleared on refresh failure
    Minor: Hard-coded timeout value in retry path
  Assessment: Ready to proceed

You: [Fix loading state reset]
[Continue to Task 3]
```

## Integration with Workflows

**Executing Plans:**
- Review after each declared batch or when the route enters reviewer stage
- 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
- Open a second review path that bypasses the active task state file
- 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