// Use when completing tasks, implementing major features, or before merging to verify work meets requirements
| name | requesting-code-review |
| description | Use when completing tasks, implementing major features, or before merging to verify work meets requirements |
Run a structured review pass to catch issues before they cascade.
Core principle: Review early, review often.
Mandatory:
Optional but valuable:
1. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
2. Run structured code review checklist:
Use requesting-code-review/code-reviewer.md template and review the diff against requirements. In Antigravity single-flow mode, do not dispatch generic coding agents.
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 summary3. Act on feedback:
[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)
[Run checklist-based review]
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
[Review 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]
Single-Flow Task Execution:
Executing Plans:
Ad-Hoc Development:
Never:
If reviewer wrong:
See template at: requesting-code-review/code-reviewer.md
Use when you have a written implementation plan and need to execute it in Antigravity single-flow mode
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when executing implementation plans, handling multiple independent tasks, or doing structured task-by-task development with review gates in Antigravity.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification