| name | wz:receiving-code-review |
| description | 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 |
Stop. Before you start working — what does your phase checklist say? Go read .wazir/runs/latest/phases/ and follow it. Every item, not just the ones that feel important. What's the first unchecked item?
Code Review Reception
Command Routing
Follow the Canonical Command Matrix in hooks/routing-matrix.json.
- Large commands (test runners, builds, diffs, dependency trees, linting) → context-mode tools
- Small commands (git status, ls, pwd, wazir CLI) → native Bash
- If context-mode unavailable, fall back to native Bash with warning
Codebase Exploration
- Query
wazir index search-symbols <query> first
- Use
wazir recall file <path> --tier L1 for targeted reads
- Fall back to direct file reads ONLY for files identified by index queries
- Maximum 10 direct file reads without a justifying index query
- If no index exists:
wazir index build && wazir index summarize --tier all
Overview
Code review requires technical evaluation, not emotional performance.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.
Loop Tracking
When receiving review findings, the fix-and-re-review cycle follows the review loop pattern:
- Pipeline mode (
.wazir/runs/latest/ exists): track iterations via wazir capture loop-check. If the cap is reached (exit 43), escalate to the user with current state and evidence.
- Standalone mode (no
.wazir/runs/latest/): the loop runs for pass_counts[depth] passes (quick=3, standard=5, deep=7) with no cap guard. Track iteration count manually.
Reference docs/reference/review-loop-pattern.md for the full loop contract.
The Response Pattern
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
Forbidden Responses
NEVER:
- "You're absolutely right!" (explicit CLAUDE.md violation)
- "Great point!" / "Excellent feedback!" (performative)
- "Let me implement that now" (before verification)
INSTEAD:
- Restate the technical requirement
- Ask clarifying questions
- Push back with technical reasoning if wrong
- Just start working (actions > words)
Handling Unclear Feedback
IF any item is unclear:
STOP - do not implement anything yet
ASK for clarification on unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
Example:
the user: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.
Look at your recent actions. Did each one follow from a checklist item, or are you improvising? Improvisation means drift. Go back to .wazir/runs/latest/phases/ and realign. Where did you go off-script?
WRONG: Implement 1,2,3,6 now, ask about 4,5 later
RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
Source-Specific Handling
From the user
- Trusted - implement after understanding
- Still ask if scope unclear
- No performative agreement
- Skip to action or technical acknowledgment
From External Reviewers
BEFORE implementing:
1. Check: Technically correct for THIS codebase?
2. Check: Breaks existing functionality?
3. Check: Reason for current implementation?
4. Check: Works on all platforms/versions?
5. Check: Does reviewer understand full context?
IF suggestion seems wrong:
Push back with technical reasoning
IF can't easily verify:
Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
IF conflicts with the user's prior decisions:
Stop and discuss with the user first
Rule: External feedback - be skeptical, but check carefully.
YAGNI Check for "Professional" Features
IF reviewer suggests "implementing properly":
grep codebase for actual usage
IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
IF used: Then implement properly
Rule: If we don't need this feature, don't add it.
Implementation Order
FOR multi-item feedback:
1. Clarify anything unclear FIRST
2. Then implement in this order:
- Blocking issues (breaks, security)
- Functional issues (wrong behavior)
- Quality improvements (structure, naming)
- Nice-to-haves (if time permits)
3. Test after each change
4. Report what you changed and why
Quick Reference
| Situation | Action |
|---|
| Clear feedback, technically sound | Implement, test, report |
| Feedback unclear | Ask for clarification before touching code |
| Feedback technically wrong | Push back with reasoning |
| Feedback contradicts user's decisions | Stop, discuss with user |
| "Implement properly" suggestion | YAGNI check first |
| Multiple items, some unclear | Clarify ALL unclear items before implementing ANY |
Almost done? Then you should be able to list every phase checklist item and show exactly where you completed it with real evidence. If you can't do that, you're not actually done. Can you list them all with proof?
