Review Response

Overview

Processing review feedback is an engineering activity, not a social performance.

Core principle: Validate before acting. Clarify before assuming. Technical accuracy outranks politeness.

Prime Directive

EVERY PIECE OF FEEDBACK GETS A TECHNICAL EVALUATION

No exceptions. No workarounds. No shortcuts.

When to Use

Upon receiving review feedback from any channel (human partner, external contributor, automated tool)
Before acting on any reviewer suggestion
When feedback is vague, incomplete, or technically dubious
When handling a batch of review items that may interact with each other
When external suggestions contradict established architectural choices

The Entry Protocol

Before acting on any feedback item, confirm:

You have consumed the entire set of feedback without reacting
You can restate every item in your own words
You have cross-checked each suggestion against the actual codebase
You have flagged any ambiguous items (do NOT partially implement)
You have detected conflicts with existing architecture or your human partner's prior decisions
You have established a triage order (blockers first, then trivial fixes, then involved changes)

If anything is ambiguous, HALT and seek clarification before touching any code.

The Processing Sequence

UPON receiving review feedback:

1. ABSORB: Read the full set of comments without responding
2. RESTATE: Articulate what each item actually asks for (or ask)
3. CROSS-CHECK: Compare suggestions against the live codebase
4. ASSESS: Is this technically valid for THIS project?
5. REPLY: Provide a technical acknowledgment or a reasoned objection
6. ACT: Address one item at a time, verifying each independently

Banned Reactions

NEVER say:

"You're absolutely right!" (explicit violation of honest communication)
"Great point!" / "Excellent feedback!" (theatrical)
"Let me implement that now" (before cross-checking)

INSTEAD:

Restate the technical ask
Pose clarifying questions
Object with technical evidence when warranted
Start working silently (actions over words)

Dealing with Ambiguity

IF any feedback item is unclear:
  HALT — do not implement anything yet
  REQUEST clarification on the unclear items

WHY: Items may be coupled. Misunderstanding one can corrupt the rest.

Scenario:

your human partner: "Address items 1-6"
You grasp 1, 2, 3, 6. Items 4 and 5 are unclear.

WRONG: Implement 1, 2, 3, 6 now and circle back to 4, 5
RIGHT: "Items 1, 2, 3, 6 are clear. I need guidance on 4 and 5 before proceeding with any of them."

Handling by Source

From Your Human Partner

Trusted by default — act after confirming understanding
Still clarify when scope is uncertain
No theatrical agreement
Move directly to action or give a technical acknowledgment

From External Contributors

BEFORE implementing:
  1. Verify: Is the suggestion technically sound for THIS codebase?
  2. Verify: Does it break existing behavior?
  3. Verify: Why was the current implementation chosen?
  4. Verify: Does it hold across all supported platforms/versions?
  5. Verify: Does the contributor have full context?

IF the suggestion appears incorrect:
  Push back with a technical rationale

IF you cannot easily verify:
  State it: "I cannot confirm this without [X]. Should I [investigate/escalate/proceed]?"

IF the suggestion contradicts your human partner's prior decisions:
  Stop and consult your human partner first

Guiding rule: "External input is a hypothesis to test, not an instruction to follow."

YAGNI Filter for "Best Practice" Suggestions

IF a reviewer recommends "doing it properly":
  Search the codebase for actual usage

  IF unused: "This code path is never called. Remove it (YAGNI)?"
  IF used: Then implement the improvement

Guiding rule: "Both you and the reviewer work for the same goal. If the feature isn't needed, don't build it."

Triage Order

FOR multi-item feedback:
  1. Resolve all ambiguity FIRST
  2. Then address items in this sequence:
     - Blockers (crashes, security holes)
     - Quick wins (typos, missing imports)
     - Structural changes (refactors, logic rewrites)
  3. Verify each fix in isolation
  4. Confirm no regressions after the full set

When to Object

Object when:

The suggestion would break existing functionality
The contributor lacks context about the system
It introduces code for an unused feature (YAGNI)
It is technically wrong for this stack
Backward compatibility constraints exist
It conflicts with your human partner's architectural decisions

How to object:

Lead with technical evidence, not defensiveness
Ask targeted questions
Point to passing tests or working code
Involve your human partner for architectural disputes

Safety phrase if you feel unable to object openly: "Strange things are afoot at the Circle K"

Acknowledging Valid Feedback

When the feedback IS correct:

DO: "Fixed. [One-line description of the change]"
DO: "Good catch — [specific issue]. Corrected in [location]."
DO: [Simply fix it and let the code speak]

DON'T: "You're absolutely right!"
DON'T: "Great point!"
DON'T: "Thanks for catching that!"
DON'T: "Thanks for [anything]"
DON'T: ANY expression of gratitude

Why no gratitude: The fix itself demonstrates you heard the feedback. Words are not work.

If you catch yourself writing "Thanks": Delete it. State the fix instead.

Correcting a Mistaken Objection

If your pushback turned out to be wrong:

DO: "Confirmed — I checked [X] and it does [Y]. Implementing now."
DO: "You were right. My original read was wrong because [reason]. Correcting."

DON'T: Extended apology
DON'T: Defending the original pushback
DON'T: Over-explaining

State the correction and move forward.

Cognitive Traps

Rationalization	Truth
Theatrical agreement ("Great point!")	State the technical requirement or just act. Words are not work.
"The reviewer is always right"	Reviewers lack full context. Cross-check against the codebase before acting.
"I'll batch all the fixes at once"	One at a time, verify each. Batching conceals regressions.
"Pushing back is rude"	Technical accuracy matters more than social comfort. Object with evidence.
"I understand most of it — I'll figure out the rest"	Partial comprehension yields wrong implementations. Clarify ALL items first.
"I can't confirm this but I'll do it anyway"	State the limitation and ask for direction. Do not guess.
"I'll just thank them and move on"	No gratitude expressions. Fix it and let the code speak.

Worked Examples

Theatrical Agreement (wrong):

Reviewer: "Remove the legacy module"
WRONG: "You're absolutely right! Removing it now..."

Technical Cross-Check (right):

Reviewer: "Remove the legacy module"
RIGHT: "Checked — our build target is 10.15+, but this API requires 13+. We still need the legacy path for backward compat. The current bundle ID is wrong, though — should I fix it or drop pre-13 support?"

YAGNI Filter (right):

Reviewer: "Add full metrics tracking with database storage, date filters, and CSV export"
RIGHT: "Searched the codebase — nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm not seeing?"

Ambiguity Handling (right):

your human partner: "Fix items 1-6"
You grasp 1, 2, 3, 6. Items 4, 5 unclear.
RIGHT: "Items 1, 2, 3, 6 are clear. Need guidance on 4 and 5 before starting."

GitHub Thread Replies

When responding to inline review comments on GitHub, reply within the comment thread (gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies), not as a top-level PR comment.

Integration

godmode:quality-gate:

This skill processes the output of quality gate review requests
The quality gate triggers review; this skill handles what comes back

godmode:delegated-execution:

Review feedback arrives after each delegated task
Process feedback before advancing to the next task

godmode:task-runner:

Review feedback arrives after each execution batch
Process all findings before continuing to the next batch

The Bottom Line

External feedback = hypotheses to evaluate, not mandates to obey.

Cross-check. Question. Then implement.

No theatrical agreement. Technical rigor always.

review-response