Habilidades receiving-code-review
📦

receiving-code-review

Seguro

Manejar comentarios de revisión de código con rigor técnico

También disponible en: Cygnusfear,ZhanlinCui,DYAI2025,obra,davila7,CodingCossack,Cycleaddict

La revisión de código requiere evaluación técnica, no rendimiento emocional. Esta guía ayuda a los asistentes de IA a verificar los comentarios antes de implementar, hacer preguntas clarificadoras y proporcionar objeciones fundamentadas cuando las sugerencias no son técnicamente sólidas.

Soporta: Claude Codex Code(CC)
🥉 72 Bronce
1

Descargar el ZIP de la skill

2

Subir en Claude

Ve a Configuración → Capacidades → Skills → Subir skill

3

Activa y empieza a usar

Pruébalo

Usando "receiving-code-review". Revisor: Eliminar la ruta de código legacy para versiones antiguas de API

Resultado esperado:

Verificando requisitos de compatibilidad... El objetivo de compilación es 10.15+, pero esta API necesita 13+. La ruta legacy aún se necesita para compatibilidad hacia atrás. Sin embargo, la implementación actual tiene el ID de bundle incorrecto. Puedo corregir el ID del bundle o podemos eliminar el soporte pre-13. ¿Qué dirección prefieres?

Usando "receiving-code-review". Revisor: Corregir elementos 1-6 en el PR

Resultado esperado:

Entiendo los elementos 1, 2, 3 y 6. Necesito clarificación sobre los elementos 4 y 5 antes de implementar. ¿Puedes elaborar sobre qué cambios buscas en esos dos elementos?

Usando "receiving-code-review". Revisor: Agregar manejo adecuado de errores con lógica de reintento y backoff exponencial

Resultado esperado:

Corregido. Agregué Try/Catch con lógica de reintento (3 intentos, backoff exponencial comenzando en 100ms) a la llamada API en api_service.rb:42-58. Las pruebas pasan.

Auditoría de seguridad

Seguro
v1 • 2/24/2026

Static analysis flagged 24 instances of backtick patterns and 4 blocker patterns, but all are FALSE POSITIVES. The skill file (SKILL.md) is documentation-only markdown containing instructional text for AI behavior. No executable code, network calls, file operations, or cryptographic functions exist. The backtick patterns are markdown code blocks showing workflow examples, not shell execution. Blocker patterns are misidentified text fragments in documentation.

1
Archivos escaneados
219
Líneas analizadas
0
hallazgos
1
Auditorías totales
No se encontraron problemas de seguridad
Auditado por: claude

Puntuación de calidad

38
Arquitectura
100
Mantenibilidad
87
Contenido
32
Comunidad
100
Seguridad
100
Cumplimiento de la especificación

Lo que puedes crear

Asistente de IA recibiendo revisión humana

Un asistente de IA recibe comentarios de revisión de código de un desarrollador humano y necesita determinar qué elementos implementar, cuáles necesitan clarificación y cuáles objetar con razonamiento técnico.

Desarrollador junior aprendiendo a responder a revisiones

Un desarrollador junior aprende a responder a los comentarios de desarrolladores senior con rigor técnico en lugar de acuerdo performativo, verificando sugerencias antes de la implementación ciega.

Contribuidor externo manejando comentarios de mantenedores

Un contribuidor externo recibe comentarios de los mantenedores del proyecto y necesita evaluar si las sugerencias se adaptan a la arquitectura del proyecto antes de implementar.

Prueba estos prompts

Solicitud de clarificación básica 
Recibí comentarios de revisión de código con 6 elementos. Entiendo los elementos 1, 2, 3 y 6, pero necesito clarificación sobre los elementos 4 y 5 antes de proceder. ¿Puedes explicar qué cambios buscas en esos elementos específicos?
Objeción técnica con evidencia 
Tu sugerencia de eliminar la capa de compatibilidad con versiones anteriores rompería la compatibilidad con macOS 10.15. La implementación actual apunta a 10.15+ pero usa APIs que necesitan 13+. ¿Debería corregir el ID del bundle para mantener la compatibilidad hacia atrás, o eliminar completamente el soporte pre-13?
Verificación de YAGNI antes de implementación 
El revisor sugirió implementar seguimiento completo de métricas con almacenamiento en base de datos, filtros de fecha y exportación CSV. Busqué en la base de código y no encontré llamadores para este endpoint. ¿Debería eliminarlo siguiendo YAGNI, o hay uso que me estoy perdiendo?
Corrección elegante después de una objeción incorrecta 
Objecioné tu sugerencia, pero después de verificar los resultados de la prueba tenías razón. Mi comprensión era incorrecta porque perdí la falla de la prueba de integración. Implementando la corrección ahora.

Mejores prácticas

  • Siempre verificar los comentarios contra la base de código real antes de implementar cualquier cambio
  • Implementar los cambios de uno en uno y probar cada uno individualmente para detectar regresiones temprano
  • Objetar con razonamiento técnico cuando las sugerencias romperían funcionalidad existente

Evitar

  • Decir '¡Totalmente tienes razón!' o '¡Buena observación!' antes de verificar el comentario
  • Implementar comentarios ciegamente sin verificar si rompen funcionalidad existente
  • Implementar los elementos 1-3 y 6 mientras se omiten los elementos confusos 4-5 sin preguntar primero

Preguntas frecuentes

¿Qué debo hacer si los comentarios de revisión de código no están claros?
Detente y pide clarificación antes de implementar cualquier cosa. Los elementos pueden estar relacionados, y el entendimiento parcial lleva a implementación incorrecta. Indica claramente cuáles elementos entiendes y cuáles necesitan clarificación.
¿Cuándo es apropiado objetar los comentarios del revisor?
Objeta cuando la sugerencia rompe funcionalidad existente, el revisor carece de contexto completo, viola YAGNI para funciones no usadas, es técnicamente incorrecta para tu stack, o entra en conflicto con decisiones arquitectónicas.
¿Cómo puedo objetar sin ser defensivo?
Usa razonamiento técnico, haz preguntas específicas, referencia pruebas funcionales o código existente, e involucra a tu socio humano si el problema es arquitectónico. Declara hechos, no emociones.
¿Qué pasa si objeté y después estaba equivocado?
Reconoce la corrección factualmente: 'Tenías razón - verifiqué X y hace Y. Implementando ahora.' Evita largas disculpas o defender por qué objetaste inicialmente.
¿Por qué debo evitar decir gracias o ser performativo?
Las acciones hablan más que las palabras. Simplemente corrige el problema y muestra el cambio en código. El acuerdo performativo desperdicia tiempo y puede enmascarar preocupaciones técnicas reales que necesitan abordarse.
¿Cómo manejo los comentarios de revisores externos de manera diferente a mi socio humano?
Sé más escéptico con revisores externos. Verifica si las sugerencias son técnicamente correctas para tu base de código, no romperán funcionalidad existente, y que el revisor entiende el contexto completo. Objeta con razonamiento cuando sea necesario.

Detalles del desarrollador

Autor

sickn33

Licencia

MIT

Repositorio

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/receiving-code-review

Ref.

main

Estructura de archivos

📄 SKILL.md