code-review-response
npx machina-cli add skill 686f6c61/alfred-dev/code-review-response --openclawResponder a code review
Resumen
Este skill gestiona la respuesta técnica a comentarios de code review. El objetivo no es aceptar todo el feedback ciegamente ni rechazarlo por ego, sino evaluarlo técnicamente y responder con evidencia. Un buen proceso de code review mejora el código; un mal proceso genera fricción y resentimiento.
La clave es tratar cada comentario como una oportunidad de mejorar el código o de enriquecer la discusión técnica del equipo.
Proceso
-
Leer todos los comentarios antes de responder a ninguno. Obtener una visión global del feedback. A veces un comentario individual cobra sentido diferente cuando se ve junto con los demás. Agrupar mentalmente por temática: estilo, lógica, arquitectura, rendimiento.
-
Clasificar cada comentario:
- Correcto y accionable: el revisor ha detectado un problema real. Implementar el cambio.
- Correcto pero discutible: el revisor tiene razón en el diagnóstico pero la solución propuesta no es la mejor. Contraargumentar con alternativa.
- Cuestión de estilo: no hay bien o mal objetivo, es preferencia. Si el proyecto tiene guía de estilo, seguirla. Si no, aceptar a menos que haya buena razón para no hacerlo.
- Incorrecto: el revisor ha malinterpretado el código o el contexto. Explicar con datos, no con autoridad.
- Fuera de alcance: el comentario es válido pero no pertenece a este PR. Crear un issue para abordarlo después.
-
Verificar si el comentario es correcto. Para cada comentario técnico:
- Leer el código señalado con ojos frescos.
- Si el comentario reporta un bug, intentar reproducirlo.
- Si sugiere un cambio de rendimiento, medir antes de aceptar.
- Si propone un refactoring, verificar que los tests cubren el área afectada.
-
Responder con evidencia, no con opiniones. Si se acepta el cambio, implementarlo y responder con el commit que lo resuelve. Si se rechaza, explicar por qué con datos: métricas de rendimiento, referencia a una decisión de diseño documentada, test que demuestra que el comportamiento es correcto.
-
Implementar los cambios aceptados. Cada cambio derivado de code review se hace en un commit separado y descriptivo que referencie el comentario original cuando sea posible.
-
No tomárselo como algo personal. El code review es sobre el código, no sobre la persona. Si un comentario resulta brusco, responder al contenido técnico e ignorar el tono.
Criterios de éxito
- Todos los comentarios del code review tienen una respuesta (aceptación, rechazo argumentado o discusión).
- Los cambios aceptados están implementados y commiteados.
- Los rechazos están argumentados con evidencia técnica, no con opiniones.
- Los comentarios fuera de alcance se han registrado como issues para seguimiento.
- El tono de las respuestas es profesional y constructivo.
Source
git clone https://github.com/686f6c61/alfred-dev/blob/main/skills/desarrollo/code-review-response/SKILL.mdView on GitHub Overview
Este skill gestiona la respuesta técnica a comentarios de code review, evitando aceptar todo sin duda y evitando peleas. Se busca evaluar el feedback, responder con evidencia y enriquecer la discusión técnica del equipo para mejorar el código y las decisiones de diseño.
How This Skill Works
Se leen todos los comentarios para obtener una visión global, se agrupan por temática y se clasifican como correcto y accionable, correcto pero discutible, cuestión de estilo, incorrecto o fuera de alcance. Luego se verifica cada comentario con evidencia (reproducir bugs, medir rendimiento, verificar pruebas). Finalmente se responde con datos y, si corresponde, se implementan cambios en commits descriptivos que referencian el comentario original.
When to Use It
- Al recibir feedback en un PR y necesitar una respuesta técnica fundamentada
- Cuando hay discrepancias entre la solución propuesta y el feedback, y se requiere contraargumentar con una alternativa
- Al identificar posibles bugs o impactos de rendimiento y requerir verificación antes de aceptar
- Cuando se debe aplicar una guía de estilo del proyecto o justificar por qué se sigue o no se aplica
- Cuando hay comentarios fuera de alcance del PR y es necesario registrar un issue para seguimiento
Quick Start
- Step 1: Lee todos los comentarios y agrúpalos por temática (estilo, lógica, rendimiento, arquitectura).
- Step 2: Clasifica cada comentario y verifica su veracidad con código, pruebas y métricas.
- Step 3: Responde con evidencia y aplica cambios en commits descriptivos; si es fuera de alcance, crea un issue.
Best Practices
- Leer todos los comentarios antes de responder para obtener una visión global
- Clasificar y priorizar comentarios por su impacto técnico y verificación necesaria
- Verificar cada comentario con evidencia: reproducir bugs, medir rendimiento y validar con tests
- Responder con evidencia y, si corresponde, referenciar el commit que resuelve el comentario
- Crear commits descriptivos por cada cambio derivado del code review y documentar la referencia al comentario original
Example Use Cases
- Detectas una regresión de rendimiento en un bucle; reproduces el problema, propones una refactorización y aplicas un commit separado con la mejora respaldada por métricas
- Un revisor propone un cambio de estilo; sigues la guía de estilo del proyecto y, si no hay guía, documentas la razón para seguir la preferencia
- Identificas un posible bug a través de la lectura del código señalado; reproduces, añades una prueba y aplicas un fix verificado por la batería de tests
- Se discute una solución compleja; presentas una alternativa más legible con justificación de complejidad y verificas que el comportamiento es equivalente
- Comentarios fuera de alcance se registran como un issue para gestionar en el backlog y no bloquean el PR
