# Superpowers Receiving Code Review

> >

- **Type:** Skill
- **Install:** `agentstack add skill-viksant-swe-skills-superpowers-receiving-code-review`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [viksant](https://agentstack.voostack.com/s/viksant)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [viksant](https://github.com/viksant)
- **Source:** https://github.com/viksant/swe-skills/tree/main/skills/superpowers-receiving-code-review

## Install

```sh
agentstack add skill-viksant-swe-skills-superpowers-receiving-code-review
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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](https://github.com/viksant)
- **Source:** [viksant/swe-skills](https://github.com/viksant/swe-skills)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-viksant-swe-skills-superpowers-receiving-code-review
- Seller: https://agentstack.voostack.com/s/viksant
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.