Responder Observación de Revisión
Resuelve una observación de revisión de código insertando un comentario aclaratorio en el lugar adecuado del código fuente, capturando el razonamiento para que futuros revisores no vuelvan a plantear la misma inquietud.
Entradas
Deduce ambas entradas del contexto de la conversación. Pregunta solo si es ambiguo.
Entrada 1 — La observación.
Un hallazgo del revisor: normalmente una fila de tabla con una ubicación (archivo:línea) y una descripción de la inquietud.
La tabla suele provenir de la habilidad dakubo-display-pr-remarks o dakubo-review-commit-range. Si no hay ninguna tabla en la conversación y una de estas habilidades está disponible, úsala para generar la tabla. Si no, pídele al usuario la observación.
Entrada 2 — La explicación.
La respuesta del desarrollador: por qué el código es correcto tal como está, la decisión de diseño detrás de él, la compensación aceptada o el contexto general que el revisor pasaba por alto. Puede que no refute directamente la observación; simplemente puede cambiar la perspectiva del revisor.
Proceso
- Lee el archivo en la ubicación indicada en la Entrada 1.
- Identifica la construcción exacta a la que apunta la observación (método, bloque, campo, línea).
- Redacta un comentario que:
- Capture la esencia de la Entrada 2 (el razonamiento/decisión/contexto).
- Sea conciso: entre una y cuatro líneas como máximo.
- No mencione al revisor, al PR ni al número de observación (los comentarios sobreviven a las revisiones).
- No repita lo que el código ya dice; añada solo el PORQUÉ que no es obvio al leerlo.
- Aborde la inquietud de la observación si hacerlo aclara la explicación, pero esto es opcional.
- Coloca el comentario inmediatamente encima de la construcción objetivo, o en línea si un comentario al final encaja de forma natural.
- Aplica la edición.
Salida
Confirma el archivo y la línea donde se añadió el comentario. Una oración es suficiente.
Lo que NO debe hacerse
- No reescribir el código a menos que el usuario lo solicite explícitamente.
- No escribir un comentario que simplemente repita lo que el código hace.
- No hacer referencia a "el revisor dijo…" o "PR #N" dentro del comentario.
- No añadir un comentario de más de ~4 líneas; si la explicación necesita más, pertenece a un documento de diseño o mensaje de commit, no en línea.