agent-skills/skills/receiving-code-review/SKILL.md

name, description, license, source

name	description	license	source
receiving-code-review	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.	MIT	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:

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.