mr-feedback

¿Qué hace mr-feedback?

Obtén un Merge Request de GitLab, evalúa qué tan listo está para ser revisado y escribe un informe de retroalimentación en un nuevo archivo markdown que se puede copiar directamente en una nota del MR.

Qué hacer

Evalúa la preparación para revisión. Verifica si el MR tiene el contexto, claridad de alcance, instrucciones de prueba y guía para el revisor que permitan a un revisor iniciar la revisión de manera eficiente.

Por qué

Un MR bien preparado indica cuidado y se revisa más rápido y mejor. El informe debe hacer que un buen MR se sienta reconocido y que uno más débil reciba pasos concretos y alentadores para mejorar su preparación.

Qué no hacer

No revises ni critiques el código en sí mismo y no sugieras cambios de código/lógica.

Preferencias

Antes de hacer cualquier otra cosa, lee reference/preferences.md (relativo a esta skill). Es la fuente de verdad para todo el comportamiento configurable: idioma de salida, tono, método de obtención, herramientas permitidas y ruta de salida. Este SKILL.md no reafirma esos valores; léelos siempre del archivo de preferencias.

Precedencia, de mayor a menor:

1. Una instrucción explícita en la solicitud actual del usuario (por ejemplo, "esta vez escríbelo en portugués").
2. reference/preferences.md.
3. Instrucciones en esta skill.

Entradas

El usuario proporciona una de:

• Una URL completa del MR: https://gitlab.com/<grupo>/<subgrupo>/<proyecto>/-/merge_requests/<iid>
• Una ruta de proyecto + iid del MR: grupo/subgrupo/proyecto + 42

Analiza desde la URL:

• project_id = la ruta entre el host y /-/merge_requests/ (codifica como grupo%2Fsubgrupo%2Fproyecto al llamar herramientas)
• mergeRequestIid = el número después de /-/merge_requests/

Si alguno falta o es ambiguo, pregunta antes de obtener.

Flujo de trabajo

Usa el método y las herramientas declaradas en reference/preferences.md. Los pasos a continuación indican qué información recopilar y por qué, no qué herramienta llamar: elige la herramienta correspondiente de las preferencias para cada uno.

1. Metadatos del MR - título, descripción, autor, estado, rama origen/destino, flag de borrador, etiquetas, hito, aprobaciones, estado de fusión.
2. Lista de archivos cambiados - rutas + conteo de agregados/eliminaciones; proporciona alcance/tamaño sin obtener cada diff.
3. Diferencias de muestra para confirmar que la descripción coincide con la realidad - en lotes de 3-5 archivos. Usa esto solo para verificar el alcance y si se tocaron pruebas - no para criticar el código. Omite archivos de bloqueo, archivos generados y cambios de nombre puros; toma muestra si el MR es enorme.
4. Commits - usa el resumen de commits ya incluido en los metadatos del MR (paso 1) para señal de higiene/atomicidad (cantidad de commits / resumen de adiciones).
5. Estado de CI - el estado de la última canalización para el MR (pasó/falló/no tiene).
6. Evalúa según la rúbrica en reference/rubric.md.
7. Escribe el informe en un nuevo archivo (ver Salida) usando reference/report-template.md.
8. Informa al usuario la ruta del archivo y ofrécete a refinar tono/extensión antes de que lo copie/pegue.

Lee reference/rubric.md antes de puntuar y reference/report-template.md antes de escribir. No inventes datos - si una obtención no devuelve nada para una categoría (por ejemplo, sin canalización), márcala como "no disponible" en lugar de adivinar.

Cada categoría de la rúbrica incluye una Razón que explica por qué es importante para el autor. Cuando informes una brecha en "Para mejorar la preparación", incluye siempre por qué es importante para el autor - de modo que la retroalimentación explique el propósito detrás de cada solicitud, no solo la solicitud misma.

No copies la Razón de la categoría textualmente. La Razón es el contexto que cubre toda la categoría; reescríbela para que se ajuste al problema exacto que encontraste. Menciona solo lo específico que está mal y nunca menciones aspectos de la categoría que estén bien. Por ejemplo, si la rama está atrasada respecto a master pero la canalización está en verde, explica por qué estar atrasada respecto a master importa - no menciones la canalización en absoluto, ya que pasó. El "por qué importa" debe ser cierto para la brecha específica de este MR, no una declaración genérica sobre la categoría.

Salida

Escribe en la ruta de salida declarada en reference/preferences.md, resolviendo sus marcadores de posición y creando las carpetas que la ruta necesite.

Barreras de seguridad

• Solo lectura. Esta skill nunca publica notas, aprueba ni modifica el MR. Solo escribe un archivo markdown local. El usuario decide si pegarlo.
• No incluyas secretos/tokens que puedan aparecer en los diffs en el informe.
• Si el MR es un borrador o aún no tiene diff, aún puedes evaluarlo y generar el informe, pero asegúrate de ser explícito al respecto.