Título y descripción de MR / PR
Todo lo escrito en el MR/PR (título, descripción) y cada pregunta formulada al usuario está en francés. Diga « MR » para GitLab y « PR » para GitHub.
Argumentos (opcionales)
Contenido recibido: $ARGUMENTS
| Argumento | Destino |
|---|---|
https://github.com/<propietario>/<repo>/pull/<n> | PR de GitHub |
https://<host>/<grupo>/<repo>/-/merge_requests/<iid> | MR de GitLab |
#<n> / <n> solo | MR o PR del repo actual: inferir la plataforma desde git remote -v |
| nada | MR o PR de la rama actual: inferir la plataforma desde git remote -v |
Si no se puede inferir la plataforma (host autoalojado, varios remotos), pregunte.
Reglas estrictas
- Nunca modifique el MR/PR sin confirmación explícita del título y de la descripción, luego una autorización explícita separada para enviar.
- Nunca invente hechos (número de tarjeta, contexto, pruebas). Pregunte u omita.
- No mencione a Claude en el contenido del MR/PR.
Pasos
1. Identificar y obtener el MR/PR
Resuelva el destino a partir de los argumentos (tabla anterior), luego lea la referencia correspondiente antes de ejecutar cualquier comando:
references/sources/gitlab.mdreferences/sources/github.md
Si la CLI (glab / gh) falta o no está autenticada, dígale al usuario (sugiera ! glab auth login / ! gh auth login) en lugar de adivinar.
Recupere: título actual, descripción actual, ramas origen/destino y los cambios (diff y lista de commits), siguiendo la referencia. Lea el diff para comprender el contenido real del MR/PR.
Determine:
- Nombre del repo: último segmento de la ruta del proyecto, en MAYÚSCULAS.
- Número de tarjeta: busque en el título existente, nombre de rama, commits y descripción (ej.
ABC-123,#123). Si no encuentra ninguno, pregunte una vez; si el usuario dice que no hay, omita los corchetes por completo.
2. Título
Patrón (igual en ambas plataformas):
[<número de tarjeta>] <NOMBRE DEL REPO> - <asunto> - descripción corta
- Corchetes y número de tarjeta solo si existe una tarjeta.
<NOMBRE DEL REPO>: nombre del repo en mayúsculas.<asunto>: pregunte siempre al usuario por él (proponga una sugerencia inferida del diff como opción predeterminada, pero no decida solo). Si el título actual ya contiene un asunto, proponga mantenerlo.- Descripción corta: sucinta, en francés, comienza en minúscula, sin punto final.
- Si un título existente ya está bien formado y sigue ajustándose al contenido del MR/PR, manténgalo y dígalo. Si ya no se ajusta, proponga uno modificado y muestre el antes/después.
3. Descripción
Estructura (Markdown, en francés):
# Descripción
<Una o dos oraciones que resuman el objetivo del MR/PR.>
## Contexto
<Estado actual del código si es una modificación; resultado esperado: restricciones, objetivos, arquitectura, estrategia.>
## Cambios
- <Cambio de alto nivel>
- ...
## Pruebas
- <Pruebas escritas, o pruebas manuales realizadas>
Orientación por sección:
- Descripción: 1–2 oraciones sobre el objetivo. Proponga un borrador y pida al usuario que lo valide o corrija.
- Contexto: describe el estado anterior (para una modificación) y el resultado esperado (restricciones, objetivos, arquitectura, estrategia). Vaya punto por punto: someta cada punto al usuario para validación y haga una pregunta siempre que un punto pueda aclararse (por qué esta elección, qué restricción, qué alternativa rechazada). No avance con suposiciones no validadas.
- Cambios: solo lista de alto nivel. Entre en detalle solo cuando el cambio trate precisamente sobre ese detalle o cuando sea esencial para comprender el MR/PR en su conjunto.
- Pruebas: pinceladas de las pruebas automatizadas escritas (archivos/áreas cubiertas) y las pruebas manuales realizadas. Si se desconoce, pregunte; nunca afirme pruebas que no se realizaron.
Prefiera agrupar preguntas relacionadas con AskUserQuestion (asunto, número de tarjeta, puntos de contexto) en lugar de muchos viajes de ida y vuelta.
4. Descripción existente (caso de actualización)
Si el MR/PR ya tiene una descripción:
- Muestre qué cambiaría, sección por sección (añadido / modificado / eliminado), no solo el texto nuevo.
- Conserve el contenido útil que el usuario escribió (enlaces, capturas de pantalla, listas de verificación, secciones de plantilla, palabras clave de cierre como
Closes #12); menciónelo si algo se eliminaría. - Pida confirmación de los cambios antes de continuar.
5. Confirmar, luego enviar
- Presente el título final, el MR/PR destino (URL, ramas) y la descripción completa, y pida confirmación de los tres.
- Solo después, haga una pregunta separada: autorización para enviar las modificaciones a la plataforma.
- Tras la aprobación, escriba la descripción en un archivo temporal/scratchpad y actualice el MR/PR con el comando de la referencia de la plataforma. Estos comandos no están en
allowed-toolsa propósito para que el usuario reciba un aviso de permiso. - Informe el resultado y la URL del MR/PR. Si falla, muestre el error; no reintente en silencio.