requesting-code-review

name	requesting-code-review
description	Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Requesting Code Review

Dispatch globalcoder-development: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:

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 globalcoder-development: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 globalcoder-development: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

Common Rationalizations

Excuse	Reality
"It's just a small change, no review needed"	Small changes ship the same bugs as large ones. Review takes minutes; debugging shipped bugs takes hours.
"I already self-reviewed carefully"	Self-review and external review catch different classes of issue. The whole point is fresh eyes.
"The implementing agent already verified it works"	"Works" ≠ "is correct, idiomatic, secure, and matches the plan." That's what review is for.
"I'll batch up several tasks and review at the end"	Defeats "review early, review often" — issues compound across tasks and become harder to untangle.
"I'm under time pressure"	The bug you ship now costs more time later. Review is the cheaper option.
"The reviewer will probably just say LGTM"	If so, fine — but skipping review on that bet means you discover problems in production instead.
"The reviewer's feedback is wrong, I'll just ignore it"	Push back with technical reasoning and code/test evidence. Silent ignore is not pushback.
"Minor nits aren't worth a follow-up"	Note them. Patterns of "minor" feedback often reveal real architectural drift.

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: skills/requesting-code-review/code-reviewer.md (relative to plugin root)