PixiBixi/claude-skills

Abordando Comentarios de Revisión de MR de GitLab

Resumen

Los comentarios de revisión en línea en una MR de GitLab viven en discusiones (hilos anclados a un archivo+línea). Todo el ciclo (obtener con posición → corregir → responder → resolver) se ejecuta a través de glab api. Esta skill es la secuencia de comandos probada; el detalle es que el comando obvio (glab mr view --comments) te da el texto del comentario pero no la posición archivo/línea, por lo que no puedes saber a qué se refiere cada comentario.

ANTECEDENTES REQUERIDOS: Usa superpowers:receiving-code-review para la parte de juicio: evalúa cada comentario con rigor técnico y verifica que sea correcto antes de aplicarlo. Esta skill solo cubre la mecánica de GitLab.

Configuración

MR=511                                          # el iid de la MR
PROJ="<grupo>%2F<subgrupo>%2F<proyecto>"         # ruta completa codificada para URL
API="projects/$PROJ/merge_requests/$MR"

Codifica la ruta para URL (/ → %2F). Si no estás seguro, obténla con glab repo view.

1. Obtener comentarios CON posición

glab mr view $MR --comments NO incluye posiciones de línea, así que no lo uses para comentarios en línea. Usa la API de discusiones y analiza position. --paginate es obligatorio: el endpoint devuelve 20 hilos por página, y sin él el resto se descartan sin error. Se saltan los hilos ya resueltos:

glab api --paginate --output ndjson "$API/discussions" | python3 -c '
import sys, json
for line in sys.stdin:
    d = json.loads(line)
    n = d["notes"][0]
    if n.get("system") or n.get("resolved"): continue
    p = n.get("position") or {}
    print(d["id"], "|", n["author"]["username"], "|", n["body"])
    if p: print("   ->", p.get("new_path"), "new_line:", p.get("new_line"), "old_line:", p.get("old_line"))
'

• new_line = la línea en el archivo actual (post-cambio) → esto es lo que lees para interpretar el comentario.
• Un comentario en una línea cambiada lleva tanto old_line como new_line; ancla en new_path + new_line.
• Sin position → es un comentario general (no en línea).

2. Leer el código en cada new_path:new_line, luego corregir

Abre el archivo en la línea citada para que el comentario tenga sentido en contexto. Aplica la corrección solo después de evaluarla (ver receiving-code-review). Haz commit como un solo commit de corrección de revisión y haz push:

git add <archivos>
git commit -m "fix(<alcance>): aborda revisión sobre <cosa>"   # Conventional Commits, id del ticket en el cuerpo
git fetch origin <target> && git rebase origin/<target>
git push --force-with-lease   # un `git push` simple solo es suficiente si el rebase no hizo cambios

3. Responder y resolver cada hilo

Publicar en el endpoint notes de una discusión auto-enhebra la respuesta (no se necesita in_reply_to_id). Luego haz PUT resolved=true:

DISC="<id de discusión del paso 1>"
glab api -X POST "$API/discussions/$DISC/notes" -f "body=Hecho: <lo que cambiaste>."
glab api -X PUT  "$API/discussions/$DISC?resolved=true"

Nunca envuelvas glab en una función de shell: las reglas de permiso solo coinciden con el comando literal, así que escribe ambas llamadas completas para cada hilo.

Escribir la respuesta

Mantén solo lo que cambió y por qué. Un revisor quiere el delta, no la investigación.

• Aplicado: una o dos oraciones. Qué cambiaste, si ampliaste algo más allá de la línea citada, el sha del commit. Hecho, estilo de bloque en todas partes: los seis componentes, no solo esta línea. La salida renderizada sin cambios. f6511f29
• En desacuerdo o diferido: primero el hecho decisivo, luego la opción, y la pelota de vuelta en su tejado. Dos párrafos cortos como máximo. Elimina la consideración lateral, el tercer argumento de apoyo, el cierre "feliz de discutir".
• Nunca narres la secuencia de tus propias correcciones, y nunca repitas el comentario del revisor de vuelta.

Qué hilos resolver

Resuelve solo aquellos que realmente cerraste.

• Aplicaste el cambio -> responde + resuelve.
• Respondiste una pregunta y la respuesta la resuelve -> responde + resuelve.
• Una decisión que no es tuya (entorno objetivo, alcance, prioridad) -> responde, no resuelvas. Resolver un hilo que el revisor aún debe arbitrar se lee como si lo ignoraras, y desaparece de su lista de revisión.

Referencia rápida

Paso	Comando
Listar comentarios en línea + posición	glab api --paginate --output ndjson "$API/discussions" → analiza .notes[].position.{new_path,new_line,old_line}
Responder a un hilo	glab api -X POST "$API/discussions/<id>/notes" -f "body=..."
Resolver un hilo	glab api -X PUT "$API/discussions/<id>?resolved=true"

Errores comunes

• Usar glab mr view --comments para comentarios en línea: da el texto sin archivo/línea; no puedes ubicarlos. Usa la API de discusiones.
• Inventar glab mr note resolve: resuelve mediante glab api -X PUT ".../discussions/<id>?resolved=true".
• Leer old_line en lugar de new_line: para un comentario en una línea cambiada, el código actual está en new_line.
• Olvidar --paginate: más allá de 20 hilos, la API de discusiones devuelve silenciosamente solo la primera página.
• --force simple después del rebase: usa --force-with-lease, para que no se sobrescriba un commit que el revisor haya subido mientras tanto.
• Aplicar comentarios a ciegas: evalúa primero (receiving-code-review). Responde con lo que realmente cambiaste, luego resuelve.
• Truncar el id de discusión al listar hilos: la API quiere el id completo de 40 caracteres, un prefijo de 8 caracteres devuelve 404 Discusión no encontrada. Imprime d["id"] completo.
• Explicar demasiado en la respuesta: ver "Escribir la respuesta". El razonamiento pertenece a la descripción de la MR o al ticket.
• Resolver una decisión diferida: si el revisor aún debe elegir, deja el hilo abierto.