receiving-code-review
npx machina-cli add skill parthalon025/autonomous-coding-toolkit/receiving-code-review --openclawCode 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!" (performative)
- "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)
When To Push Back
Push back when:
- 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
- Ask specific questions
- Reference working tests/code
Implementation Order
FOR multi-item feedback:
1. Clarify anything unclear FIRST
2. Then implement in this order:
- Blocking issues (breaks, security)
- Simple fixes (typos, imports)
- Complex fixes (refactoring, logic)
3. Test each fix individually
4. Verify no regressions
The Bottom Line
External feedback = suggestions to evaluate, not orders to follow.
Verify. Question. Then implement. No performative agreement. Technical rigor always.
Source
git clone https://github.com/parthalon025/autonomous-coding-toolkit/blob/main/skills/receiving-code-review/SKILL.mdView on GitHub Overview
Code review requires technical evaluation, not social performance. Core principle: verify before implementing; ask before assuming; prioritize technical correctness over feelings or appearances.
How This Skill Works
Follow the pattern: READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT. Read feedback completely, restate or clarify the requirement, verify against the real codebase, evaluate technical correctness for this stack, respond with a technical acknowledgment or reasoned pushback, and implement changes one item at a time with tests.
When to Use It
- Feedback is unclear or technically questionable and requires verification before acting
- The reviewer lacks full context or project-wide constraints
- A suggestion risks breaking existing functionality or violates YAGNI
- The change conflicts with architectural decisions or stack conventions
- You need to provide technical reasoning or ask clarifying questions before implementing
Quick Start
- Step 1: Read the entire feedback without reacting
- Step 2: Restate the requirement or ask clarifying questions, then verify against the codebase
- Step 3: Implement items one at a time, with tests and verification after each
Best Practices
- Restate the technical requirement or ask clarifying questions early
- Push back with concrete technical reasoning supported by code or tests
- Verify against the codebase and tests before changing behavior
- Implement changes one item at a time and test each independently
- Aim for correctness and maintainability, not blind agreement
Example Use Cases
- Reviewer suggests renaming a function without considering all call sites; verify scope and impact
- Feedback asks to remove a feature due to style preferences, but it’s required for functionality
- A proposed refactor seems risky; push back with tests showing no regressions
- Reviewer proposes adding functionality not used in current code path; confirm necessity
- You receive vague feedback like “improve readability” and ask for concrete criteria
