OpenSkillIndex← back to search
claude-code

Awesome-vibe-coding receiving-code-review

Use when receiving code review feedback, before implementing suggestions — requires technical rigor and verification, not performative agreement

install
source · Clone the upstream repo
git clone https://github.com/adriannoes/awesome-vibe-coding
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/adriannoes/awesome-vibe-coding "$T" && mkdir -p ~/.claude/skills && cp -r "$T/cursor/skills/receiving-code-review" ~/.claude/skills/adriannoes-awesome-vibe-coding-receiving-code-review && rm -rf "$T"
manifest: cursor/skills/receiving-code-review/SKILL.md
source content

Receiving Code Review

Source: obra/superpowers (MIT)

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

The Response Pattern

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (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

Forbidden Responses

NEVER:

  • "You're absolutely right!"
  • "Great point!" / "Excellent feedback!"
  • "Let me implement that now" (before verification)

INSTEAD:

  • Restate the technical requirement
  • Ask clarifying questions
  • Push back with technical reasoning if wrong
  • Just start working (actions > words)

Handling Unclear Feedback

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

Implementation Order

FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement: blocking issues → simple fixes → complex fixes
  3. Test each fix individually
  4. Verify no regressions

When To Push Back

  • Suggestion breaks existing functionality
  • Reviewer lacks full context
  • Violates YAGNI (unused feature)
  • Technically incorrect for this stack
  • Conflicts with architectural decisions

How to push back: Use technical reasoning, not defensiveness. Reference working tests/code.

Acknowledging Correct Feedback

When feedback IS correct:

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch — [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]

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

Why no thanks: Actions speak. Just fix it.

The Bottom Line

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Then implement. No performative agreement. Technical rigor always.