Skills

Receiving Code Review

Use when receiving code review feedback before implementing suggestions, especially...

Install

npx skills add GanyuanRan/Aegis --skill receiving-code-review -g -a claude-code -y
Repository
GanyuanRan/Aegis1.4k
Category
Git and review
Updated
11d ago
License
MIT
Context cost
Lightabout 1,498 tokens
Runs scripts
No, instructions only

What it does

Use when receiving code review feedback before implementing suggestions, especially when feedback is unclear, risky, disputed, or technically questionable.

Code Review Reception

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!" (explicit CLAUDE.md violation)
  • "Great point!" / "Excellent feedback!" (performative)
  • "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.

Example:

your human partner: "Fix 1-6"
You understand 1,2,3,6. Unclear on 4,5.

āŒ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
āœ… RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."

Source-Specific Handling

From your human partner

  • Trusted - implement after understanding
  • Still ask if scope unclear
  • No performative agreement
  • Skip to action or technical acknowledgment

From External Reviewers

BEFORE implementing:
  1. Check: Technically correct for THIS codebase?
  2. Check: Breaks existing functionality?
  3. Check: Reason for current implementation?
  4. Check: Works on all platforms/versions?
  5. Check: Does reviewer understand full context?

IF suggestion seems wrong:
  Push back with technical reasoning
Read the whole SKILL.md on GitHub

More in Git and review