dx-swe-receiving-review

Guides verification and implementation of code review feedback with technical rigor.

3|5|Updated Jan 21, 2025
One-click install
npx skills add https://github.com/DEEPX-AI/dx_stream --skill dx-swe-receiving-review-deepx-ai
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dx-swe-receiving-review
Source: https://github.com/DEEPX-AI/dx_stream/tree/main/.deepx/skills/dx-swe-receiving-review
Command: npx skills add https://github.com/DEEPX-AI/dx_stream --skill dx-swe-receiving-review-deepx-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Receiving code review feedback often leads to two failure modes: performative agreement without verification, or blind implementation of suggestions that may break the codebase. This Skill enforces a disciplined response pattern so every review comment is read, understood, verified against the actual codebase, and only then implemented or pushed back on with technical reasoning. ## Core Features & Use Cases - Structured Response Pattern: Enforces a six-step flow (read, understand, verify, evaluate, respond, implement) for every piece of review feedback. - Source-Specific Handling: Distinguishes trusted feedback from your human partner versus external reviewer suggestions that require skepticism and verification. - YAGNI and Pushback Checks: Prompts codebase verification (e.g., grepping for actual usage) before adding requested features, and supports reasoned pushback when suggestions are wrong. - Use Case: A reviewer asks to remove legacy compatibility code. Instead of agreeing, you check build targets, discover the API requires a newer OS version, and respond with the technical constraint plus options. ## Quick Start Use the dx-swe-receiving-review skill to evaluate and respond to the code review comments on my current pull request.

Frequently Asked Questions about dx-swe-receiving-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How should I respond to code review feedback on a pull request?▼

Read all feedback completely, restate each requirement in your own words, verify it against the actual codebase, then implement one item at a time with testing. Avoid performative agreement like "great point" and instead state the fix or ask clarifying questions.

How do I handle unclear code review comments before implementing?▼

Stop and ask for clarification on any unclear items before implementing anything. Partial understanding leads to wrong implementations, especially when feedback items are related, so clarify all ambiguous points first.

When should I push back on a code review suggestion?▼

Push back when a suggestion breaks existing functionality, violates YAGNI by adding unused features, is technically incorrect for your stack, or conflicts with prior architectural decisions. Use technical reasoning and reference working code or tests rather than being defensive.

Should I implement every suggestion from external reviewers?▼

No. External feedback should be treated as suggestions to evaluate, not orders. Verify each suggestion is technically correct for your codebase, check it does not break existing functionality, and confirm the reviewer understands the full context before implementing.

What is the correct order for implementing multi-item review feedback?▼

Clarify unclear items first, then implement blocking issues like breaks and security fixes, followed by simple fixes like typos, and finally complex refactoring. Test each fix individually and verify no regressions occur.