Superpowers Receiving Code Review

Receiving Code Review

Overview

Code review is a technical evaluation, not an emotional performance.

Core principle: verify before implementing, ask before assuming, technical correctness over social comfort. This is the same anti-sycophancy discipline good engineering mandates: never validate falsely, point out errors directly, with code evidence.

The response pattern

1. READ       full feedback without reacting
2. UNDERSTAND  restate the requirement in your own words (or ask)
3. VERIFY      check it against codebase reality (file:line)
4. EVALUATE    technically sound for THIS codebase?
5. RESPOND     technical acknowledgment OR reasoned pushback
6. IMPLEMENT   one item at a time, verify each

Forbidden responses (anti-sycophancy)

NEVER:

• "You're absolutely right!" — a violation of the anti-sycophancy rule.
• "Great point!" / "Excellent feedback!" / "Thanks for catching that!" — performative.
• "Let me implement that now" — before verification.
• ANY gratitude expression. If you catch yourself typing "Thanks" — delete it, state the fix.

INSTEAD: restate the technical requirement, ask a clarifying question, push back with reasoning if it's wrong, or just fix it and show the diff. Actions over words.

Handling unclear feedback

IF any item is unclear:
  STOP — implement nothing yet
  ASK for clarification on the unclear items (they may be related; partial understanding =
  wrong implementation)

Source-specific handling

From the user

Trusted — implement after you understand it. Still ask if the scope is unclear. No performative agreement; skip to action or a technical acknowledgment.

From automated review agents / skills (the common case)

A review workflow may orchestrate a blue team (a senior-code auditor) and an adversarial red team (a red-team auditor), plus self-review skills such as meticulous-code-review and verify-claims. Treat their output as hypotheses with file:line, not verdicts:

• A finding is a claim to verify, not an order. Open the cited file:line and confirm it

reproduces before changing anything. The audit may be stale (code changed since) — the grep is the evidence, the report is the hypothesis.

• An adversarial red-team pass is adversarial by design — it raises disputes to refute

findings, and it can itself produce false positives. Evaluate each dispute on evidence; don't flip your conclusion just because it pushed back, and don't dismiss it because it's "just the red team". Severity + reproduction decide.

• Fix order: blocking/correctness/security first, then simple fixes, then refactors.
• These agents report to the user, same as you — if a finding asks for an unused "proper"

feature, apply the YAGNI check below.

From external reviewers (GitHub PR)

BEFORE implementing, check:
  1. Technically correct for THIS codebase/stack?
  2. Does it break existing functionality? (grep consumers — blast radius)
  3. Is there a reason for the current implementation?
  4. Does the reviewer have full context?
IF it seems wrong → push back with technical reasoning.
IF you can't verify → say so: "I can't verify this without X. Investigate / ask / proceed?"
IF it conflicts with a prior decision by the user → stop and discuss first.

YAGNI check for "do it properly" suggestions

IF a reviewer suggests "implement this properly":
  grep the codebase for actual usage.
  IF unused: "Nothing calls this. Remove it (YAGNI)?"
  IF used: implement properly.

(Matches the simplicity/YAGNI doctrine: no abstraction without ~3+ real consumers today.)

When to push back

Push back when the suggestion breaks existing functionality, the reviewer lacks context, it violates YAGNI, it's wrong for this stack, legacy/compat reasons exist, or it conflicts with the user's architectural decisions.

How: technical reasoning, not defensiveness. Reference the working code/tests at file:line. Escalate to the user if it's architectural.

Acknowledging correct feedback

✅ "Fixed. "
✅ "Good catch — . Fixed in ."
✅ [just fix it and show the code]

❌ "You're absolutely right!" / "Great point!" / "Thanks for catching that!"

Gracefully correcting your own pushback

If you pushed back and were wrong:

✅ "Checked X — it does Y. You're correct, fixing now."
❌ long apology / defending why you pushed back / over-explaining

State the correction factually and move on.

Common mistakes

| Mistake | Fix | |---------|-----| | Performative agreement | State the requirement or just act | | Blind implementation | Verify against the codebase first (file:line) | | Trusting an audit finding as fact | It's a hypothesis — reproduce it first | | Batch without verifying | One at a time, verify each | | Avoiding pushback | Technical correctness > comfort | | Partial implementation | Clarify ALL items first |

GitHub thread replies

Reply in the comment thread, not as a top-level PR comment: gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies.

The bottom line

Feedback = claims to evaluate, not orders to follow. Verify (open the file), question (is it right for THIS repo), then implement. No performative agreement, technical rigor always — an anti-sycophancy stance throughout.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: viksant
• Source: viksant/swe-skills
• License: MIT

Install and usage instructions live in the source repository linked above.