Receiving Code Review

Receiving Code Review

Overview

Core Principle: Validate feedback first, then decide whether to implement it.

Use This Skill

• You have already received code review feedback.
• The feedback contains multiple modification suggestions.
• Some suggestions are unclear, or you suspect they might introduce regressions.
• You need to distinguish what must be fixed, what can be refuted, and what needs clarification first.

Do Not Use

• There are no review results yet; use requesting-code-review first.
• The user just wants a normal code review, rather than processing feedback.
• The current task is implementing a feature from scratch, not responding to review comments.

Execution Protocol

1. Read Feedback Completely First

Do not start modifying code upon seeing the first comment. First confirm:

• How many feedback items there are in total.
• Which ones are blocking issues.
• Which ones are unclear.
• Which ones might be related to each other.

2. Reiterate Technical Understanding

If there are multiple feedback items, clarify your understanding of the scope before acting:

I understand items 1, 2, and 3 are...
The scope of items 4 and 5 is not clear enough and needs confirmation first.

3. Validate If Feedback Is Valid

Check each item:

• Does the codebase currently actually have this problem?
• Is the suggested fix suitable for the current tech stack and existing constraints?
• Will it break existing behavior, compatibility, or architectural decisions?
• Is it just "looks more standard" but actually unneeded by anyone?

4. Categorize Handling

• Clear and correct: Implement directly.
• Unclear: Clarify first, then implement.
• Technically invalid: Provide evidence to refute.
• Trade-off needed: Confirm the direction with the user before proceeding.

Handling Unclear Feedback

If you cannot accurately explain the meaning of a piece of feedback, do not start modifying it.

Incorrect approach:

• Modify what you understand first, and guess the rest as you go.

Correct approach:

• Point out which items are understood.
• Explicitly list which items need clarification.
• Wait for clarification before advancing as a whole.

When To Refute

You should refute or request further justification when:

• The suggestion would break existing functionality.
• The reviewer lacks context.
• The suggestion violates YAGNI, and no one in the codebase uses it.
• The current implementation is limited by compatibility, platform, or historical constraints.
• It conflicts with established architectural decisions.

When refuting, provide:

• Specific file or implementation evidence.
• Existing tests or behavioral proof.
• Alternative solutions or specific questions.

Implementation Order

When there are multiple feedback items, recommended order:

1. Blocking issues.
2. Clear and small fixes.
3. Complex logic or refactoring items.
4. Style and maintainability items.

Re-validate between each item; do not pile up many changes at once.

Trae / Windows Conventions

• When processing feedback, prioritize using Read, Grep, SearchCodebase, GetDiagnostics, and necessary validation commands to verify facts.
• When needing to clarify multiple feedback items with the user or partner, prioritize using structured, concise questions instead of guessing while doing.
• Re-validate every time you fix an item; if you finally want to declare it "fixed", go through verification-before-completion.

Failure Handling

• Unable to validate a piece of feedback: Explicitly state the missing context or dependency.
• Feedback items conflict with each other: Stop and request the user to determine priority.
• You initially refuted, but later realized you were wrong: Directly admit the validation result and start fixing; do not make long excuses.
• Fixing one item introduces a new problem: Return to the validation phase, confirm if the scope needs to be expanded.

Output Contract

When processing feedback, the output must at least contain:

• Which feedback items you understood.
• Which items have been validated as true.
• Which items still need clarification.
• Which items you plan to implement or refute.
• Once all feedback items are resolved, must invoke verification-before-completion to re-verify before declaring "fixed".

Integration

• requesting-code-review: Initiates the independent review.
• verification-before-completion: Performs final validation after feedback is fixed.

Bottom Line

Code review feedback is technical input to be validated, not an absolute command that must be blindly followed.