| name | pc-receiving-code-review |
| description | Use when review feedback has arrived and the author must verify, sequence, and respond to comments without blind agreement, especially when suggestions may conflict with brownfield constraints, contracts, or existing architecture decisions. |
| metadata | {"phase":"05-quality","inputs":["review-report","source-code","test-suite"],"outputs":["review-response-record"],"prerequisites":["pc-code-review"],"quality_gate":"Every review item is understood, verified against current codebase reality, and either implemented with evidence or answered with technical reasoning","roles":["developer","tech-lead"],"methodologies":["all"],"effort":"small"} |
Receiving Code Review
Treat review feedback as technical input to verify, not as a script to perform.
Context
pc-receiving-code-review is the author-side companion to reviewer-side pc-code-review.
See context and anti-pattern notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 1: Read the Whole Review Before Acting
Do not start implementing the first comment immediately. Read the full review and group items into:
- blocking corrections
- clarifications needed
- technically questionable suggestions
- optional improvements
If multiple comments appear related, keep them together until the interaction is understood as a whole.
Step 2: Clarify Before Partial Implementation
If any review item is ambiguous, stop and ask before changing code. Do not implement the subset you understand while guessing at the rest.
Clarify when:
- the requested behavior is unclear
- the suggested scope is larger than the current slice
- the comment may conflict with an architecture or product boundary
- the reviewer appears to assume context that is not visible in the diff
Step 3: Verify Against Codebase Reality
For each review item, check:
- does the suggestion fit the current code and tests
- does it preserve brownfield compatibility and unsupported-flow rules
- does it violate YAGNI or introduce unused complexity
- does it conflict with reviewed architecture or contract decisions
- is the reviewer pointing at the real defect, or only at a local symptom
If the feedback is correct, implement it. If not, respond with technical reasoning and evidence instead of social agreement.
Step 4: Respond Factually, Not Performatively
Do not write praise or social filler such as:
- "You're absolutely right"
- "Great point"
- "Excellent feedback"
Instead:
- restate the technical issue
- say what changed
- say what remains unclear
- say why the suggestion should not be applied when evidence contradicts it
Step 5: Implement One Verified Item at a Time
Apply accepted feedback in a controlled order:
- blocking correctness or security fixes
- scope-safe cleanups
- optional or stylistic improvements last
Run the relevant tests after each meaningful change. If one item reopens another, record that explicitly instead of silently batch-editing everything at once.
Step 6: Produce a Review Response Record
Produce a review-response-record that captures:
- each review item
- whether it was implemented, challenged, or clarified
- the evidence used to decide
- the tests or checks run after accepted changes
- any remaining disputed items that still need reviewer or user resolution
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
