Receiving code review

Skill lawzava/megapowers/plugins/megapowers/skills/receiving-code-review

Skills, plugins, and hooks that change how coding agents work — Claude Code, Codex, OpenCode, Antigravity. Measured, not vibed.

Install

npx -y skills add lawzava/megapowers --skill receiving-code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use to evaluate review feedback before changing code, especially unclear or suspect suggestions. Triggers on reviewer comments or requested changes. Not for requesting review.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.8 KB, as published. Nobody here has run it

Code Review Reception

Overview

Code review is a technical evaluation, not an emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

The Response Pattern

Work through feedback in this order: read it fully, understand it (restate the requirement in your own words or ask), verify it against the actual code, evaluate whether it is technically sound for this codebase, respond substantively, then implement one item at a time, testing each. Keep the review axes distinct. A Specification Compliance Fail blocks proceeding regardless of local finding severity: correct the implementation or obtain explicit requirement-owner authorization, then re-review. For Engineering Standards, fix Critical findings immediately, address Important findings before proceeding, and record Minor findings for later.

No Performative Agreement

Never respond with "You're absolutely right!", "Great point!", "Excellent feedback!", or "Thanks for catching that!". Restate the requirement, ask a clarifying question, push back with technical reasoning, or just fix it; the code itself shows you heard the feedback.

When feedback is correct, respond with the fix and a brief statement of what changed. When you pushed back and were wrong, state the correction factually and move on; skip the apology and the defense of your original position.

Unclear Feedback

Clarify every unclear item before implementing any of them. Items are often related, so partial understanding produces wrong implementations. "I understand items 1, 2, 3, 6. Need clarification on 4 and 5 before proceeding" beats implementing the four you understand and asking about the rest later.

Source Matters

From your human partner: trusted, so implement after understanding. Still ask when scope is unclear.

From external reviewers: verify before implementing. Is the suggestion technically correct for this codebase and stack? Does it break existing behavior or a supported platform? Is there a reason for the current implementation the reviewer cannot see? If you cannot verify, say so and ask for direction. If it conflicts with your human partner's prior decisions, stop and discuss with them first.

Your human partner's rule: "External feedback — be skeptical, but check carefully."

YAGNI Check

When a reviewer suggests adding or "properly implementing" a feature, check whether the codebase actually needs it (grep for real usage) or whether it just sounds thorough. If nothing uses it, propose removal instead of building it out.

Your human partner's rule: "You and the reviewer both report to me. If we don't need this feature, don't add it."

Pushing Back

Push back when a suggestion is technically wrong, breaks working behavior, violates YAGNI, ignores a legacy or compatibility constraint, or conflicts with your human partner's architectural decisions. Argue with technical reasoning and working code or tests, not defensiveness, and involve your human partner when the disagreement is architectural. If pushing back feels uncomfortable, name that tension and raise the issue anyway.

GitHub Thread Replies

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

The Bottom Line

External feedback is a set of suggestions to evaluate, not orders to follow.

Verify. Question. Then implement.