work-review-receive

Verifies code review feedback against the codebase and implements accepted fixes in severity order.

3|3|Updated Apr 6, 2026
One-click install
npx skills add https://github.com/philipobenito/elelem --skill work-review-receive-philipobenito
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: work-review-receive
Source: https://github.com/philipobenito/elelem/tree/main/skills/work-review-receive
Command: npx skills add https://github.com/philipobenito/elelem --skill work-review-receive-philipobenito

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Review feedback arrives from many sources—PR comments, reviewer subagents, bots, or your human partner—and acting on it blindly leads to unverified changes, silent agreement with wrong suggestions, and partial implementations that break things. This Skill enforces a disciplined procedure: verify each item against the codebase, push back with technical reasoning where the reviewer is wrong, and implement only what survives. ## Core Features & Use Cases - Source-based trust rules: Feedback from your human partner is trusted and clarified, while feedback from bots, subagents, and other external sources must be verified against the code before acting. - Structured response procedure: Read all items first, assign severity tiers where missing, verify each item, sort into accept/pushback/unclear, and implement in severity order with per-fix testing. - Mandatory pushback rules: Push back with cited evidence when a suggestion breaks functionality, conflicts with prior decisions, violates YAGNI on unused code, or is technically incorrect for the stack. - Use Case: A reviewer subagent returns five findings on your pull request. The Skill verifies each against the code, implements the three valid ones in severity order, pushes back on one that breaks macOS 10.15 compatibility, and asks a clarifying question on the last before touching anything. ## Quick Start Address the review comments on this pull request by verifying each item, pushing back where the reviewer is wrong, and implementing the valid fixes in severity order.

Frequently Asked Questions about work-review-receive

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

FAQPage Schema
How do I handle code review feedback from multiple sources?

Apply source-based trust rules: feedback from your human partner is trusted and only needs scope clarification, while feedback from bots, subagents, and others must be verified against the codebase first. Then sort each item into accept, pushback, or unclear before implementing anything.

How to respond to pull request review comments on GitHub?

Reply to inline review comments in the comment thread using gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies. Do not post top-level PR comments, since they detach the response from the comment it answers and make the review thread unreadable.

When should I push back on a code review suggestion?

Push back when the suggestion breaks existing functionality, ignores context like platform support or prior decisions, violates YAGNI on unused code, or is technically incorrect for your stack. Ground the pushback in evidence: cite the file, test, version constraint, or prior decision.

What should I do when review feedback has no severity levels?

Assign severity tiers yourself using the code review rules: Critical, Important, or Minor. State the tier you assigned for each item with your reasoning so the reviewer or partner can correct it, then implement in severity order.

Can I implement the review items I understand and ask about the rest later?

No. If any item is genuinely unclear, ask about all unclear items at once and implement nothing, including the clear ones. Review items are frequently related, so partial implementation produces wrong changes that also look like progress.

What if a reviewer asks to implement a feature properly on unused code?

Grep the codebase for actual callers first. If nothing calls the code, propose removal under YAGNI rather than building out the suggested feature. Only implement the suggestion when real usage exists.