receiving-code-review
Gestionar comentarios de revisión de código con verificación técnica
También disponible en: Cygnusfear,DYAI2025,Cycleaddict,davila7,CodingCossack,obra
La revisión de código requiere evaluación técnica, no desempeño emocional. Esta habilidad proporciona un patrón estructurado para verificar los comentarios de revisión antes de la implementación, asegurando la corrección técnica sobre la comodidad social.
Descargar el ZIP de la skill
Subir en Claude
Ve a Configuración → Capacidades → Skills → Subir skill
Activa y empieza a usar
Pruébalo
Usando "receiving-code-review". Reviewer: Remove legacy code
Resultado esperado:
Checking compatibility requirements... Build target is 10.15+, this API needs 13+. Current implementation has wrong bundle ID. Options: fix bundle ID or drop pre-13 support. Which do you prefer?
Usando "receiving-code-review". Reviewer: Implement metrics tracking with database, date filters, CSV export
Resultado esperado:
Searched codebase - no code calls this endpoint. Recommend removal per YAGNI. Is there expected usage I should know about?
Usando "receiving-code-review". Partner: Fix items 1-6
Resultado esperado:
I understand items 1, 2, 3, and 6. I need clarification on items 4 and 5 before proceeding with implementation.
Auditoría de seguridad
SeguroAll static analysis findings are false positives. The skill file (SKILL.md) is a markdown documentation file containing instructional text, not executable code. Backticks detected are markdown code block delimiters, not shell command execution. No actual cryptographic operations, network calls, or command injection vectors exist in this skill.
Puntuación de calidad
Lo que puedes crear
Respuesta a revisión con múltiples elementos
Al recibir una lista de 6+ elementos de comentarios, aclarar primero los elementos poco claros, luego implementar en orden de prioridad (problemas bloqueantes primero), probando cada cambio individualmente para detectar regresiones temprano
Escepticismo hacia revisores externos
Cuando revisores externos sugieren cambios sin contexto completo, verificar la corrección técnica para tu código base, comprobar cambios incompatibles, y rechazar con evidencia cuando la sugerencia es incorrecta
Control de características YAGNI
Cuando los revisores sugieren implementar funcionalidades 'correctamente' con base de datos, filtros y exportaciones, hacer grep del código base primero para confirmar el uso real antes de añadir complejidad innecesaria
Prueba estos prompts
I received code review feedback with items 1-6. I understand items 1, 2, 3, and 6, but items 4 and 5 are unclear. Before implementing anything, I need clarification on what exactly is expected for items 4 and 5.
A reviewer suggested changing X to Y. Let me verify: Is this technically correct for this codebase? Does it break existing functionality? What was the reason for the current implementation? I'll check the code and tests before proceeding.
I understand your suggestion to do X, but this would break Y because of Z. The current implementation handles edge case A and B. If we change this, we need to also update C and D. Should I proceed with the full scope or keep the current approach?
You suggested implementing X with full database support, date filters, and CSV export. I searched the codebase and found no callers of this endpoint. Should I remove it entirely per YAGNI, or is there usage I'm missing?
Mejores prácticas
- Siempre aclarar todos los elementos poco claros antes de implementar cualquier parte de los comentarios
- Verificar sugerencias contra el comportamiento real del código base, no solo la lógica superficial
- Rechazar con razonamiento técnico específico, no a la defensiva o con emoción
Evitar
- Decir '¡Tienes toda la razón!' o '¡Gran punto!' antes de la verificación
- Implementar comentarios inmediatamente sin verificar la realidad del código base
- Implementar múltiples elementos en lote sin probar cada cambio individualmente
Preguntas frecuentes
¿Qué debo hacer cuando los comentarios de revisión no son claros?
¿Cómo rechazo la sugerencia de un revisor?
¿Qué pasa si el revisor tiene razón y yo rechacé?
¿Debería agradecer a los revisores por sus comentarios?
¿Cómo gestiono sugerencias para implementar funcionalidades 'correctamente'?
¿En qué orden debo implementar comentarios de múltiples elementos?
Detalles del desarrollador
Autor
ZhanlinCuiLicencia
MIT
Repositorio
https://github.com/ZhanlinCui/Ultimate-Agent-Skills-Collection/tree/main/receiving-code-reviewRef.
main
Estructura de archivos
📄 SKILL.md