---
name: receiving-code-review
description: Use when acting on code-review findings from a human or delegate, especially when feedback is ambiguous, technically questionable, or may conflict with the specification or existing behavior.
license: MIT
source: https://github.com/obra/superpowers/blob/main/skills/receiving-code-review/SKILL.md
---

# Receiving Code Review

Review feedback is a claim to investigate, not a patch queue to apply blindly.
The reviewer may have missed codebase context; the implementer may be biased
toward defending their own work. Resolve both risks with evidence.

## Triage the complete review first

For every finding, record:

- exact file/line and the claimed failure;
- severity and whether it blocks the stated requirements;
- the reviewer’s proposed fix, if any;
- whether the finding is clear, verified, disputed, or needs a decision.

Read all findings before editing. Items can depend on each other, and fixing a
clear symptom before understanding a related architectural concern can create
rework.

## Verify against this codebase

For each material finding:

1. Restate the falsifiable claim: what input or state should produce what bad
   result?
2. Inspect the cited code plus its callers, tests, compatibility constraints,
   and relevant specification.
3. Reproduce the problem or add the cheapest check that distinguishes a real
   defect from a false positive.
4. Decide whether the proposed fix addresses the root cause without breaking
   existing behavior, tenant isolation, platform support, or scope.

For multi-tenant changes, explicitly test a cross-tenant negative case; a
query that returns the expected row for one tenant does not prove RLS safety.
For WordPress or infrastructure changes, verify the actual runtime convention
instead of substituting a generic framework preference.

If a finding cannot be verified with available access or artifacts, say
exactly what evidence is missing. Do not silently convert uncertainty into an
implementation decision.

## Resolve conflicts before editing

- If the finding is unclear, ask one concrete question and do not guess at the
  requested behavior.
- If it conflicts with the approved spec or a prior user decision, present the
  conflicting texts and ask which governs.
- If it requests unused “professional” machinery, search for actual callers
  and requirements first; reject scope growth that has no consumer.
- If it is technically wrong, push back with code, tests, or runtime evidence.
  Do not comply merely because the reviewer sounds confident.
- If it is correct, fix it without performative agreement. State the verified
  problem and the change.

## Implement and close findings one at a time

Order work by security/data-loss defects, other blocking correctness defects,
then non-blocking improvements. For each accepted finding:

1. Create or identify a check that fails for the reported problem.
2. Apply the smallest in-scope fix.
3. Re-run the targeted check and relevant regression tests.
4. Record the evidence and mark only that finding resolved.

Do not let the implementer’s self-review close the loop. A fresh reviewer (or
the lead model) must inspect the fix diff, and `verification-before-completion`
still applies before reporting the review resolved.

## Response format

Keep the response technical:

```text
Finding: <location and claim>
Verdict: accepted | rejected | needs decision | unverified
Evidence: <test, code path, or missing access>
Action: <fix made, reason no change was made, or exact question>
Verification: <command and result, if changed>
```

Avoid gratitude, defensiveness, or automatic agreement. The useful output is
a traceable decision backed by evidence.