br4zz4:review-receive

Guides technical evaluation and implementation of code review feedback.

Updated May 25, 2025
One-click install
npx skills add https://github.com/oporpino/commons --skill br4zz4-review-receive-oporpino
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: br4zz4:review-receive
Source: https://github.com/oporpino/commons/tree/main/ai/shared/skills/br4zz4%3Areview-receive
Command: npx skills add https://github.com/oporpino/commons --skill br4zz4-review-receive-oporpino

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Receiving code review feedback often leads to reflexive agreement, unverified implementations, or silent deferral of valid findings. This Skill enforces a disciplined workflow: verify every suggestion against the codebase before implementing, ask before assuming, and push back with technical reasoning when feedback is wrong. ## Core Features & Use Cases - Structured Response Pattern: A six-step flow (read, understand, verify, evaluate, respond, implement) that replaces performative agreement with technical evaluation. - Unclear Feedback Handling: Stops all implementation when any feedback item is ambiguous and requests clarification first, preventing partial or wrong fixes. - Out-of-Pattern Findings: Ensures reviewer findings that violate project conventions (SOLID, DRY, naming, layer boundaries) are fixed in the current PR or a follow-up, never silently deferred. - Use Case: A reviewer leaves five comments on your pull request, two of which are unclear and one that conflicts with an earlier architectural decision. The Skill guides you to clarify the unclear items first, push back on the conflicting suggestion with technical reasoning, then implement and test the valid fixes one at a time. ## Quick Start Apply the review-receive workflow to evaluate and implement the reviewer comments on my current pull request.

Frequently Asked Questions about br4zz4:review-receive

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I respond to code review feedback professionally?▼

Restate each feedback item in your own words, verify it against the codebase, then respond with a technical acknowledgment or reasoned pushback. Avoid performative phrases like "great point" and let the fixes in the diff speak for themselves.

How to handle unclear code review comments before implementing?▼

Stop and ask for clarification before implementing anything when any feedback item is unclear. Partial understanding leads to wrong implementations, so clarify all ambiguous items first, then implement the understood ones.

When should I push back on a code review suggestion?▼

Push back when a suggestion breaks existing functionality, violates YAGNI, is technically incorrect for your stack, or conflicts with prior architectural decisions. Use technical reasoning and reference tests or code, involving the team for architectural disputes.

What order should I implement multiple code review fixes?▼

Clarify unclear items first, then fix blocking issues like crashes and security problems, followed by simple fixes like typos, and finally complex logic or refactoring changes. Test each fix individually and verify no regressions.

Should out-of-pattern code findings be fixed in the same PR?▼

Out-of-pattern findings that violate project conventions should be fixed either in the current PR or in an immediate follow-up PR, but never silently deferred. Large refactors are better suited to a sequenced PR to keep review scope manageable.