Respond to Review

Quick Reference

HARD-GATE

WHEN receiving code review feedback:

1. READ:      Read all feedback completely before reacting
2. UNDERSTAND: Restate each point as a technical requirement
3. VERIFY:    Check the suggestion against the actual codebase
4. EVALUATE:  Is this technically sound for THIS codebase?
5. RESPOND:   Technical acknowledgment, clarifying question, or reasoned pushback
6. IMPLEMENT: One item at a time — test after each change
7. RE-REVIEW: Trigger a re-review if any Critical items were addressed

DO NOT start implementing before completing steps 1-4.

Core Process

Use this skill when you have received review feedback on your own Rails code (PR comments, pair review, async review). This is the counterpart to code-review, which covers giving a review.

Core principle: Verify before implementing. Technical acknowledgment over performative agreement. Re-review after significant changes.

Forbidden Responses

These responses skip verification and add zero signal:

Instead: Restate the technical requirement, ask clarifying questions, push back with reasoning if wrong, or just start implementing one item after reading all feedback.

Evaluating Feedback

Before implementing any suggestion, classify it based on the Quick Reference table above.

Pushing Back

Push back when a suggestion is technically incorrect for the codebase. Use this structure:

1. Acknowledge what the reviewer is concerned about
2. Explain the relevant codebase constraint or reason
3. Propose an alternative if one exists, or explain why no change is needed

"I see the concern about N+1 here. In this case the association is already
preloaded at line 42 via `includes(:orders)`. Adding another `eager_load`
would run a duplicate JOIN. Happy to add a comment clarifying this if helpful."

Never: Push back without technical evidence. If unsure, verify before claiming it's fine.

Implementation Order (Multi-Item Feedback)

1. Clarify anything ambiguous FIRST — before touching code
2. Critical blocking issues (crashes, security, data loss)
3. Simple fixes (typos, naming, missing requires)
4. Complex changes (refactoring, logic changes)
5. Test each fix individually — run the relevant spec after each change
6. Verify no regressions — run full suite before requesting re-review

Re-Review Trigger

After implementing feedback, decide whether to request a re-review:

Common Mistakes & Red Flags

Extended Resources

• assets/response_templates.md provide copy-ready response patterns for common review outcomes.

Output Style

When responding to review feedback, output:

1. Scope — State that the user received review feedback on their own Rails code; if the task is asking you to give a review instead, use code-review.
2. Feedback table — For each reviewer point, include: restated technical requirement, code checked, classification, decision, and response.
3. Verification evidence — Name the exact file, method, line, spec, or behavior checked before agreeing, implementing, or pushing back.
4. Reasoned pushback — When a suggestion is incorrect, use the pushback structure: reviewer concern, codebase constraint/evidence, and alternative or no-change rationale. Never push back without technical evidence.
5. Implementation order — List fixes one item at a time, with relevant spec after each logic change and full-suite regression check before re-review.
6. Re-review decision — State whether re-review is mandatory, recommended, or unnecessary based on Critical fixes, logic changes, architecture changes, or cosmetic-only work.
7. Language — Must be in English unless explicitly requested otherwise.

Integration