Receiving Code Review

tl;dr: the receiving half of the Superpowers review pair. It tells the agent to read the feedback, restate it, verify against the codebase, then respond with technical acknowledgment or a reasoned pushback — never “you’re absolutely right!” or “let me just implement that.” The forbidden-phrases list is the load-bearing piece.

What it actually does

SKILL.md (obra/superpowers, fetched 2026-09-10) prescribes a six-step response loop the agent runs before changing any code:

1. READ     — complete feedback without reacting
2. UNDERSTAND — restate the requirement, or ask
3. VERIFY   — check against codebase reality
4. EVALUATE — technically sound for THIS codebase?
5. RESPOND  — technical acknowledgment or reasoned pushback
6. IMPLEMENT — one item at a time, test each

The skill forbids a list of performative-agreement phrases by name: “You’re absolutely right!”, “Great point!”, “Let me implement that now”, any gratitude expression. The replacement is stated bluntly — “State the fix instead. Actions speak.” The skill even calls out the failure mode it expects: “If you catch yourself about to write ‘Thanks’: DELETE IT.”

The interesting carve-out is source-specific handling. Feedback from your human partner is trusted (still requires clarification, never performative agreement). Feedback from external reviewers goes through a five-point technical check (correct for this codebase, breaks existing functionality, reason for current impl, works on every platform, does the reviewer have full context). If the feedback is wrong or underspecified, the expected move is to push back with technical reasoning — and the skill names when to escalate to the human partner.

A second carve-out is the YAGNI check for any “implement this properly” reviewer comment: grep the codebase for actual usage, then ask before adding the feature. The skill credits the partner’s standing rule: “If we don’t need this feature, don’t add it.”

When to load it vs. the dispatching side

The frontmatter description is the trigger:

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable — requires technical rigor and verification, not performative agreement or blind implementation.

This skill is the receive side. The dispatch side — telling a reviewer subagent to review your work — is a separate skill: Requesting Code Review. Pair them. Loading only one half leaves the loop open.

Install

The upstream README does not document npx skills add obra/superpowers. Install is per-harness and the README enumerates thirteen of them. The most common paths:

# Claude Code — official Anthropic marketplace
/plugin install superpowers@claude-plugins-official

# Claude Code — Superpowers marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# Codex CLI — official Codex marketplace
/plugins
# search: superpowers → Install Plugin

# Cursor
/add-plugin superpowers

# Gemini CLI
gemini extensions install https://github.com/obra/superpowers

# OpenCode — host fetches install doc itself
# Say: "Fetch and follow instructions from
#       https://raw.githubusercontent.com/obra/superpowers/main/.opencode/INSTALL.md"

# Antigravity
agy plugin install https://github.com/obra/superpowers

If your host only watches a local SKILL.md, clone the repo and drop this one file:

git clone https://github.com/obra/superpowers
# place at any path your host's skill loader watches:
#   ~/.claude/skills/receiving-code-review/SKILL.md
#   .claude/skills/receiving-code-review/SKILL.md

SKILL.md is the entry point. It does not call out cross-skill dependencies, but install the rest of skills/receiving-code-review/ if you want any companion files the repo may add.

Gotchas

• The forbidden-phrases list is the skill. Strip it and the rest collapses to “be thoughtful on PR review,” which is what the agent was doing badly already. The list is named, in caps, and explicitly called an “instruction-file violation.”
• Unclear items block the whole batch. The skill is explicit: do not implement the items you understand while waiting for clarification on the rest. Partial understanding = wrong implementation.
• Source-specific handling is non-optional. External reviewers go through the five-point technical check before code changes; your human partner gets trust plus clarify-scope-only. Lumping both into the same “trusted reviewer” branch is the failure mode.
• YAGNI check on “implement properly” suggestions is mandatory. A reviewer asking for “proper metrics tracking with database, filters, CSV export” gets the grep-the-codebase response, not a sprint. The skill gives the literal script of what to say.
• Pushback when wrong, not emotional. The skill enumerates push-back triggers (breaks existing functionality, reviewer lacks full context, YAGNI, technically incorrect for this stack, legacy reasons, conflicts with architectural decisions). Tone is “technical reasoning, not defensiveness.”
• Graceful correction when pushback fails. If you pushed back and were wrong, the skill requires a factual one-liner — “you were right, I checked X and it does Y” — no apology tour, no defense of why you pushed back. The opposite — over-explaining — is also a listed failure mode.
• GitHub inline review replies belong in the thread. The skill closes with a specific instruction: use gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies, not a top-level PR comment.
• sandbox_test.verdict: untested — we read SKILL.md and the README; we did not run a code-review exchange through the skill.

Related: Requesting Code Review (obra/superpowers) — the dispatch half of the same review loop; Executing Plans (obra/superpowers) — downstream workflow once review changes are approved; Brainstorming (obra/superpowers) — upstream HARD-GATE that produces the spec being reviewed.