Structures how you respond to code review feedback so the review process stays focused, respectful, and productive. This skill separates substantive feedback from nitpicks, tracks follow-ups without losing them, and produces a record that makes merges faster and post-mortems clearer.
Use cases
- Responding to a code review with multiple comments of varying severity from different reviewers
- Disputing a review comment where you believe the suggested change would reduce readability or performance
- Tracking follow-up items from a review that was approved with a pending list of changes
- Asking clarifying questions about a comment without agreeing to implement the suggested change yet
- Closing out a review where the author addressed some comments but not others and you need to decide what to re-request
Key features
- Restate each comment in your own words to confirm you understood the reviewer's intent correctly before responding
- Classify each comment: must-fix before merge, important but post-merge, or optional nitpick that you can reasonably decline
- Reply to each comment with either a specific action you will take, a reason with evidence for declining, or a request for clarification
- Batch related fixes into single commits so the reviewer can verify each group without chasing individual one-line changes
- Mark each resolved comment as addressed and request re-review only after all must-fix items are resolved
When to Use This Skill
- When a pull request has more than three review comments and tracking them manually becomes error-prone
- When a reviewer requests a change that conflicts with a team convention or documented rationale
- When a review is blocked and you need to escalate or seek a second opinion without burning bridges
Expected Output
A structured review response log with each comment classified, resolved, or escalated, and a re-review request that clearly highlights what changed.
Frequently Asked Questions
- How do I handle a reviewer who consistently asks for changes that are out of scope?
- Politely separate scope from the current PR. Suggest filing a separate issue for out-of-scope feedback so it is tracked but does not block the current merge. This respects both the reviewer's input and the PR author's timeline.
- What if I disagree with a review comment?
- Disagreement is legitimate if you can cite evidence—team conventions, performance data, readability arguments. Avoid dismissing feedback based purely on preference. If the disagreement persists after one exchange, escalate to the team for a binding decision.
- How do I avoid losing track of review comments across a long review session?
- Use the code review platform's comment tracking rather than a separate notes file. Resolve comments inline as they are addressed so both you and the reviewer have a single source of truth.
Related
Related
3 Indexed items
Requesting code review
Frames a pull request so reviewers understand the risk profile, what has been tested, and where to focus their limited attention. This produces faster, more useful reviews because reviewers spend less time reconstructing context and more time evaluating the actual changes.
Documentation from code
Extracts architecture decisions, API contracts, and usage patterns directly from code to produce accurate documentation that stays in sync with implementation. Documentation-from-code treats code as the source of truth and generates prose from it rather than maintaining documentation as a separate artifact that diverges over time.
Security review for AI-generated code
Reviews AI-generated code for security failure modes that AI assistants commonly miss: prompt injection risks, credential exposure, dependency vulnerabilities, insecure deserialization, and access control gaps. This skill catches what agents miss when they optimize for functionality over safety, especially in code that handles user input, authentication, or external data.