receiving-code-review
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.
When NOT to Use
- Simple, unambiguous feedback you fully understand
- Direct requests from your human partner with clear intent
- When explicitly asked to "just implement this"
- Trivial corrections (typos, formatting) that need no verification
The Response Pattern
WHEN receiving code review feedback:
More from codingcossack/agent-skills-library
subagent-driven-development
Sequential subagent execution with two-stage review gates for implementation plans. Use when executing multi-task plans in current session, when tasks need fresh subagent context to avoid pollution, when formal review cycles (spec compliance then code quality) are required between tasks, or when you need diff-based validation of each task before proceeding.
9test-driven-development
Red-green-refactor development methodology requiring verified test coverage. Use for feature implementation, bugfixes, refactoring, or any behavior changes where tests must prove correctness.
7finishing-a-development-branch
Git branch completion workflow. Use when implementation is complete, tests pass, and a feature branch needs to be integrated via merge, pull request, or cleanup.
7using-git-worktrees
Git worktree–based workspace isolation for parallel or non-disruptive development. Use when work must occur without modifying or interfering with the current working tree.
5systematic-debugging
Root cause analysis for debugging. Use when bugs, test failures, or unexpected behavior have non-obvious causes, or after multiple fix attempts have failed.
5writing-plans
Structured implementation planning for multi-step development tasks. Use when you have a spec or requirements and need to break work into executable steps.
4