next-friday/next-friday-skills

Rebut

Tria los comentarios de revisión de código de IA en un pull request y respóndelos con rigor. Verifica cada hallazgo contra el código real, corrige los que son reales, refuta los falsos positivos con evidencia y responde en cada hilo, marcado como tria automatizada. El humano aún hace clic en "Resolver".

Este es el contrapunto de la revisión humana, no una copia de ella. Los revisores de IA como CodeRabbit o Gemini Code Assist publican muchos más hallazgos, mezclan errores reales con falsos positivos y son ciegos al repositorio. No conocen la configuración local de tu repositorio, las convenciones ni las herramientas, por lo que marcan patrones correctos para tu repositorio como errores, con confianza. La gravedad de un bot no es su corrección: un CRITICAL puede ser un falso positivo, y un detalle menor puede ocultar un error real.

Por qué los revisores de IA tienen su propia tria

• Ciego al repositorio. El bot no carga la configuración local de tu repositorio (un linter, formateador o verificador de tipos, lo que use tu stack) ni tus reglas internas. Marcará un patrón que TU PROPIA herramienta EXIGE. Ejemplo real (un repositorio de ESLint): un revisor marcó meta.defaultOptions como CRITICAL "incorrecto", pero la regla de lint require-meta-default-options del repositorio lo exige. Aplicar la sugerencia habría roto esa compilación. Aplicar a ciegas es tan peligroso como descartar a ciegas.
• Alta tasa de falsos positivos. Muchos hallazgos son especulativos o solo de estilo. Algunos son errores reales que el humano pasó por alto. El trabajo es separarlos con evidencia, no con corazonadas.
• Confiadamente incorrecto. Las etiquetas de gravedad son heurísticas. Verifica un CRITICAL igual que un detalle menor.

Cuando el revisor es humano

El pipeline es el mismo para cada revisor, bot o humano: verificar contra el código actual → corregir o responder con evidencia → responder en el hilo bajo la línea de atribución → probar la cobertura. Un colaborador o revisor humano también es parte del bucle de tria: cuando una persona solicita un cambio, corrígelo y responde, con el mismo rigor y la misma pista de auditoría que la compuerta humana lee al fusionar. Solo cambia el tono, porque un humano conoce el repositorio, publica menos hallazgos y de mayor señal, y tiene un rostro que una refutación brusca puede amenazar. Así que cuando el revisor es humano:

• Elimina el marco de bot. No trates su revisión como ruido ciego al repositorio y de alta tasa de falsos positivos; por lo general no lo es.
• Colabora, no refutes de forma brusca. Verifica, luego corrige lo correcto y responde a lo incorrecto con razonamiento técnico. Nunca acuerdo performativo, nunca un "falso positivo" corto dirigido a un colega; indica la razón en un tono técnicamente razonado y no brusco.
• Publica la respuesta tú mismo, con la línea de atribución. Realizas la tria de los hilos humanos de forma autónoma, igual que los hilos de bots: publica a través de la cuenta de tria, abierto con la línea de atribución para que el lector vea una tria automatizada y no la propia revisión por pares del mantenedor. La línea que desconecta el comentario del mantenedor es exactamente lo que hace que la publicación automática en un hilo humano sea segura. La cobertura también cuenta los hilos humanos (Paso 5.5), por lo que un hallazgo humano sin respuesta mantiene la ronda abierta.

Los pasos a continuación se aplican tanto a bots como a humanos; el marcador de atribución y la respuesta automática se usan para ambos. La única adaptación por revisor es el tono anterior.

Preflight

"${CLAUDE_SKILL_DIR}/scripts/preflight.sh"

preflight.sh confirma que gh está autenticado y que el repositorio tiene un remoto de GitHub. Si falta un requisito, imprime la corrección en stderr y sale con código distinto de cero; transmite eso y detente. Identifica el PR: el argumento [pr-number], o el PR de la rama actual (gh pr view --json number).

Paso 1: Reúne cada hallazgo

"${CLAUDE_SKILL_DIR}/scripts/gather-review.sh" <pr>

gather-review.sh imprime un bloque REVIEWS que contiene el autor, estado y cuerpo de cada revisión, y un bloque COMMENTS que contiene el autor, ruta:línea, id=<id> y cuerpo de cada comentario en línea, a través del --jq integrado de gh, por lo que nada se inventa ni se omite. Enumera cada hallazgo con su autor, ruta:línea, id de comentario necesario para responder y cuerpo. Incluye los resúmenes de revisión de nivel superior y cada comentario en línea. No omitas ninguno. Etiqueta el autor de cada hilo como bot, reconocible por el sufijo de inicio de sesión [bot] que se muestra en la salida recopilada, o humano: ambos siguen los Pasos 4-6, y un hilo humano además toma el ajuste de tono en "Cuando el revisor es humano" anterior.

Deja que la ronda se estabilice antes de triar. Los revisores se activan de forma asíncrona: un segundo bot a menudo publica su ola minutos después del primero, por lo que una ejecución de recopilación instantánea cuando el PR se actualiza solo captura a los revisores que han publicado hasta el momento. Después de la primera recopilación, deja que la ronda se estabilice con gh pr checks <pr> --watch || true: se bloquea hasta que las comprobaciones del PR finalizan y se comporta igual de forma interactiva y sin cabeza, y esa es la ventana en la que los revisores asíncronos publican (el || true evita que la salida distinta de cero de un PR sin comprobaciones se lea como un error). Luego vuelve a ejecutar gather-review.sh; si aparecen nuevos hallazgos, la ronda aún está llegando, así que observa y vuelve a recopilar nuevamente. (Si el PR no tiene comprobaciones, --watch regresa de inmediato; y un bot solo de revisión puede no registrar ninguna ejecución de comprobación, por lo que en ambos casos pausa brevemente y vuelve a recopilar independientemente del estado de las comprobaciones. La automatización entre rondas a continuación es el respaldo real para un revisor que publica después de que esto se estabiliza). Comienza la tria solo una vez que una nueva recopilación no agrega nada nuevo. Esto maneja una ronda con múltiples revisores como UNA pasada de tria en lugar de comenzar con los hallazgos del revisor A mientras el revisor B todavía está en medio de la publicación, lo que obliga a una segunda pasada completa. El límite evita que esto espere para siempre; la automatización entre rondas en la última sección es la respuesta duradera para los revisores que publican después de que el skill sale.

Paso 2: Verifica cada hallazgo (el núcleo de este skill)

Para cada hallazgo, responde dos preguntas contra el código actual, no el marco del bot:

1. ¿Se reproduce el problema? Reprodúcelo como describe ${CLAUDE_SKILL_DIR}/references/debugging.md: abre el archivo en la línea, rastrea la lógica, construye la entrada que describe el bot y verifica el comportamiento real. Si es un error, debe ser demostrable.
2. ¿Es la sugerencia correcta para ESTE repositorio? Ejecuta la compuerta relevante que define el repositorio (su linter, verificador de tipos o pruebas, las que existan). Verifica la convención documentada. Una corrección que pasa el bot pero falla una compuerta del repositorio es incorrecta aquí.

Cambia una cosa a la vez y vuelve a verificar. No lo hagas por lotes.

Paso 3: Clasifica

Veredicto	Significado	Acción
CORREGIR	Real, se reproduce	Corrígelo (Paso 4)
REFUTAR	Falso positivo para este repositorio	Responde con la evidencia que lo refuta
INTENCIONAL	Decisión deliberada que el bot no ve	Responde explicando la intención
MENOR	Cosmético, sin compuerta	Anótalo; corrígelo u omítelo según el estándar del mantenedor

Paso 4: Corrige los válidos

• Cambio mínimo limitado al hallazgo. Para un error, escribe primero la prueba fallida, mírala fallar, corrige, mira pasar.
• Ejecuta las compuertas completas del repositorio. Una compuerta roja bloquea la corrección.
• Entrega toda la ronda en UN commit y empuja, nunca uno por hallazgo. Verifica y corrige cada hallazgo uno por uno como en el Paso 2, pero prepara cada corrección y confírmalas juntas, luego empuja una vez, bajo la cuenta del mantenedor, la misma cuenta que posee el PR y publica las respuestas. Un empuje por hallazgo convierte un ciclo de revisión en varios: cada empuje vuelve a ejecutar CI y vuelve a activar cada bot, por lo que cinco correcciones se convierten en cinco ejecuciones de CI y cinco rondas de revisión. Un commit por ronda es una ejecución de CI y una ronda de revisión. Captura ese único SHA; cada respuesta de corrección en el Paso 5 lo cita. Si ese empuje es rechazado como no rápido debido a que la rama remota avanzó (un bump de un bot de lanzamiento o una fusión de "Actualizar rama" del PR agregó commits durante la ronda), recupérate, no te detengas: git fetch luego git rebase origin/<rama>, vuelve a ejecutar las compuertas y empuja de nuevo, nunca --force; el rebase reescribe el commit, por lo que vuelve a capturar el nuevo SHA y cita ese en las respuestas del Paso 5, no el SHA anterior al rebase.

Paso 5: Responde en cada hilo

Responde al comentario original para que se enhebre en línea, nunca un comentario de nivel superior del PR.

Abre cada respuesta con la misma línea de atribución, en cada hilo, sin excepción. Publicas a través del token gh del mantenedor, por lo que GitHub muestra su avatar y un lector asume que lo escribió. La línea de atribución nombra al agente y desconecta el comentario del mantenedor, para que la tria automatizada nunca se confunda con la propia revisión del mantenedor:

🤖 Tria automatizada por Claude Code, publicada a través de la cuenta del mantenedor, no una revisión personal.

Cuando el repositorio tiene un bot o cuenta de máquina, publica bajo esa identidad en su lugar para que el autor mismo no sea personal; la línea de atribución es el respaldo para un token personal.

Escribe el cuerpo en un archivo. La línea de atribución hace que el cuerpo sea de varias líneas, lo que rompe la cita en línea -f body="...". Una respuesta de corrección:

> 🤖 Tria automatizada por Claude Code, publicada a través de la cuenta del mantenedor, no una revisión personal.

**rebut** corregido en <sha>: <una línea sobre el cambio>.

Una refutación indica la evidencia:

> 🤖 Tria automatizada por Claude Code, publicada a través de la cuenta del mantenedor, no una revisión personal.

**rebut** no cambiando esto: <razón concreta, por ejemplo, una regla de lint del repositorio lo exige; la compuerta pasa>.

Publica cada respuesta con post-reply.sh, un hallazgo a la vez:

"${CLAUDE_SKILL_DIR}/scripts/post-reply.sh" <pr> <comment_id> /tmp/reply.md

post-reply.sh marca el ritmo de la publicación bajo el límite de tasa secundario de GitHub, luego confirma que persistió leyendo el ID de respuesta creado de la respuesta de la API, reintentando con retroceso cuando una publicación es limitada. Imprime el ID de respuesta y sale con 0 en caso de éxito; salida 1 significa que la respuesta no se publicó (no continúes, corrige y vuelve a ejecutar), salida 2 es un argumento incorrecto. No improvises la llamada gh api .../replies en un bucle: las publicaciones consecutivas superan el límite de tasa y desaparecen, exactamente el fallo que este script existe para prevenir. Un hallazgo, una llamada post-reply.sh, en secuencia.

Solo responde, nunca Resolver. Publica respuestas a través de la API; nunca hagas clic en "Resolver conversación". El botón verde Resolver es para el revisor humano, y es cómo verifica el trabajo de este skill: lee cada hilo, confirma que hay una respuesta, confirma que existe el comentario de resumen, y solo entonces resuelve. Si el skill resuelve, el humano no puede decir si ellos o el agente cerraron el hilo, exactamente la confusión que los hace volver a verificar o volver a ejecutar la tria. Toda la salida de este skill son respuestas más un comentario de resumen; el botón Resolver sigue siendo suyo.

No dejes ningún hilo en blanco. Cada hallazgo recopilado en el Paso 1 recibe una respuesta: un CORREGIR con su SHA, o un REFUTAR / INTENCIONAL / MENOR con su razón. Un hallazgo sin respuesta, de un bot o un humano, es indistinguible de un trabajo no triado: un revisor no puede decir si el skill se ejecutó, por lo que lo vuelven a invocar y la ronda se repite. El silencio nunca es un veredicto. No estar de acuerdo con un hallazgo aún requiere una razón indicada, nunca un hilo vacío.

Paso 5.5: Afirma la cobertura, vuelve a verificar CI, luego captura la ronda que provocó tu corrección push

Antes de resumir:

• Afirma la cobertura (siempre). Después de publicar, vuelve a consultar el PR y confirma que cada hallazgo, bot o humano, recibió una respuesta de la cuenta de tria:

  "${CLAUDE_SKILL_DIR}/scripts/verify-coverage.sh" <pr>
  

  Imprime una fila por hallazgo (respondido / FALTANTE) luego respondidas N / M. Salida 0 significa que cada hallazgo tiene una respuesta (la ronda está cubierta); salida 1 enumera cada hallazgo FALTANTE, por lo que vuelve a publicar esos con post-reply.sh y repite hasta que informe respondidas N / N; salida 2 es un error de lectura/argumento, que no es cobertura, así que transmiítelo. Esto se ejecuta independientemente de cuáles fueran los veredictos, incluida una ronda con todas REFUTAR donde no se empujó ninguna corrección: una respuesta de refutación omitida es tan invisible como una respuesta de corrección omitida. Nunca continúes al Paso 6 mientras algún hallazgo esté FALTANTE.

• Vuelve a verificar CI. Cuando las comprobaciones aún se están estabilizando, espera con gh pr checks <pr> --watch, luego clasifica con "${CLAUDE_SKILL_DIR}/scripts/ci-status.sh" <pr>: ci: verde (salida 0) está claro; ci: fallando (salida 1) bloquea, así que depúralo; ci: ninguna (salida 3) significa que no hay CI configurado, lo que NO es un error, así que anótalo y continúa, exactamente como lo maneja el skill implementar; ci: pendiente (salida 4) significa volver a ejecutar --watch, luego volver a sondear; un error de lectura (salida 2) no es "verde", así que transmiítelo. Confirma el verde con tus propios ojos; nunca lo afirmes sin la evidencia del script. Si el Paso 4 no cambió nada porque cada hallazgo fue REFUTAR o INTENCIONAL, no hay un nuevo push, por lo que esta nueva verificación de CI y la captura de ronda a continuación no tienen nada que reactivar; la afirmación de cobertura anterior aún se ejecuta.

• Captura la nueva ronda. El push de corrección...