Receiving Code Review
Bans performative agreement like "you're absolutely right!" — requires verifying feedback before implementing or pushing back
This skill addresses a common development task: evaluating and responding to code-review feedback before implementation. It gives practical value by discouraging blind changes, requiring clarification of ambiguous items, and applying verification and YAGNI checks. Its boundary is mainly review reception; it does not cover complete change management or stack-specific workflows.
The sequence is clear and includes stopping on ambiguity, implementing one item at a time, testing each fix, and checking for regressions. It also tells the agent to disclose when verification is not possible. However, the skill has no executable tests, input/output contract, acceptance criteria, or reproducible verification procedure across agent harnesses, so it depends substantially on the codebase, available tools, and human judgment.
The core behavior reduces risks from blind implementation, accidental removal, and incorrect architectural changes by checking compatibility, existing functionality, context, and security implications. It also asks the agent to discuss conflicts with the human partner first. The evidence does not specify least privilege, pre-change backup, rollback, sensitive-data handling, or confirmation boundaries for external actions; the GitHub reply example does not define required permissions or publication approval.
The skill supplies a process, prohibited and preferred language, decision conditions, a mistake/fix table, and examples, making its methodological claims traceable within the document. It lacks independent tests, behavioral evaluation results, a required format for citing code evidence, versioned change records, and explicit separation of facts from inferences. The examples are illustrative and do not establish real-world effectiveness.
The trigger and main workflow are easy to understand, and the document covers clear feedback, ambiguous feedback, external reviewers, YAGNI, multi-item changes, and correcting an erroneous pushback. It does not define required input formats, an output template, tool compatibility, exit criteria after test failure, costs, or troubleshooting. “Check the codebase” and “test” are not mapped to concrete interfaces.
The skill has a name and description, while repository context supplies an MIT license, a package version, and general contribution/update signals. The skill itself has no version, changelog, maintainer, response target, or explicit update path. The publisher is not verified by the FollowSkills enterprise registry, so no additional governance credit is applied.
- Do not treat the instruction to verify as evidence that verification has occurred; the document provides no executable tests or independent evaluation.
- Before applying or publishing any change, explicitly confirm scope, permissions, sensitive-data boundaries, and rollback plans; these are not sufficiently specified by the skill.
- “STOP” and “Just start working” apply to different situations. The agent must distinguish clear feedback from unresolved ambiguity and avoid modifying code or replying to external review threads without appropriate authorization.
What it does & when to use it
Standardizes how Claude reacts to code review feedback: read the complete feedback without reacting → restate the requirement in your own words (or ask) → verify against the actual codebase → judge whether it's technically sound for this codebase → respond with a technical acknowledgment or reasoned pushback → implement item by item, testing each. Explicitly bans performative agreement ("you're absolutely right!", "great point!") that skips verification, and bans implementing the parts you understood while quietly glossing over the rest.
Splits feedback sources into two tracks: from your human partner (trusted by default, but still ask if scope is unclear) versus external reviewers (verify against the actual codebase, check for breakage, check whether the reviewer has full context — push back with technical reasoning if the suggestion doesn't hold up, or say plainly "I can't verify this without X, should I investigate/ask/proceed?" if you can't check). For "implement this properly"-style suggestions, it greps the codebase first to confirm the feature is actually used — if it isn't, it proposes removing it (YAGNI) instead of building it out. For multi-item feedback, it clarifies every unclear item up front, then implements in order — blocking issues, then simple fixes, then complex fixes — testing each one individually.
- A colleague or external reviewer leaves a batch of suggestions, some vague or questionable — clarify and verify before implementing instead of taking them at face value
- A reviewer suggests "add a full metrics-tracking system," but the endpoint in question isn't called anywhere — propose removing it under YAGNI instead of building it
- Review feedback conflicts with a prior decision — push back with technical evidence (existing tests, code references) rather than caving automatically
Pros & cons
- Breaks "verify before implementing" into concrete checks (technically sound? breaks anything? does the reviewer have full context?) instead of a vague "think critically"
- Gives extensive good/bad response pairs (performative agreement vs. technical verification) that make it easy to spot when a response has gone wrong
- Handles unclear feedback specifically: clarify every item first, then implement — never silently skip the parts you didn't understand
- Only reliably self-enforcing on harnesses that actually read and follow SKILL.md instructions (Claude Code, Codex CLI, etc.) — in a plain chat interface it's just a document a human has to apply by hand.
- This is fundamentally a behavioral-standards document — its effect depends entirely on whether the harness actually enforces the SKILL.md as a hard constraint rather than treating it as optional reference
- Pushing back assumes the reviewer's suggestion really is wrong; if Claude's own understanding of the codebase is off, the pushback itself can end up being the wrong side of the argument
How to install
Installed as part of the obra/superpowers plugin — individual skills can't be installed standalone:
- Claude Code: official marketplace
/plugin install superpowers@claude-plugins-official; or register the community marketplace with/plugin marketplace add obra/superpowers-marketplacethen/plugin install superpowers@superpowers-marketplace - Also supports Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi — see the repo README for the exact command per harness
Once installed, this skill activates alongside the other 13 Superpowers skills, auto-triggered by using-superpowers based on context — there's no separate invocation step.
How to use
Triggers automatically on review feedback received during subagent-driven-development or normal development. Typical effect: on a suggestion to "remove this legacy code," Claude checks the compatibility target first before deciding to keep or remove it, instead of complying blindly.
Compared to similar skills
Compared to a one-line system-prompt reminder to "take code review seriously," this skill provides different handling strategies for internal vs. external feedback and a concrete verification checklist — cutting down on both blind acceptance and blind pushback.