code-review_skill

Overview

This skill helps you receive and act on code review feedback with technical rigor rather than performative agreement. It guides verification, clarification, and measured implementation so you fix the right things and avoid regressions. Use it whenever feedback is unclear, risky, or from an external reviewer who may lack full context.

How this skill works

Follow a short verify-then-act pattern: read feedback fully, restate the requirement, verify against the codebase, evaluate technical correctness for this project, then respond or implement. Prioritize blocking and safety issues, ask clarifying questions for anything ambiguous, and implement one item at a time with tests to prevent regressions. Treat external suggestions as proposals to vet, not orders to follow blindly.

When to use it

• Before implementing feedback that seems unclear or incomplete
• When external reviewers suggest changes without full project context
• If a suggested change might break behavior or compatibility
• When multiple related items are requested and order matters
• Before adding features flagged as potentially unused (YAGNI check)

Best practices

• Read all feedback before responding or coding to avoid partial, incorrect fixes
• Restate the requested change in your own words and ask focused clarifying questions
• Verify claims by grepping the codebase, running tests, and checking usage or docs
• Implement fixes in order: critical/security, simple fixes, then complex refactors
• Test each change individually and run regression checks before merging
• Push back with concise technical reasoning and evidence when suggestions are incorrect

Example use cases

• A reviewer asks to remove legacy code that might still support older platforms—verify usage and compatibility before removing
• An external reviewer proposes a refactor; check if it breaks existing behavior or if the endpoint is actually used (YAGNI)
• You receive a list of six inline comments but two are ambiguous—reply acknowledging understood items and request clarification for the unclear ones
• A suggestion would change API semantics—evaluate backward compatibility and consult your human partner if it conflicts with architecture
• A reviewer suggests a security fix—treat it as blocking, verify impact, implement, and add a targeted test