amanjotx/Agent-Skills

/ship

Haz commit del trabajo actual, haz push y abre una pull request. Invocar esta habilidad es permiso explícito para crear/cambiar ramas, hacer commit, push y ejecutar gh pr create.

Reglas estrictas

• Sigue el protocolo de seguridad git del usuario: nunca cambies la configuración de git; nunca omitas hooks; nunca hagas force-push a main/master; haz amend solo cuando sus reglas de amend estén completamente satisfechas.
• Nunca hagas commit de secretos (.env, credenciales, claves privadas, tokens). Advierte y exclúyelos si están presentes.
• Agrega solo archivos que pertenezcan a este cambio. No uses git add . / git add -A de forma masiva a menos que el árbol sea claramente intencional y esté limpio de basura.
• Usa HEREDOC para mensajes de commit y cuerpos de PR.
• Mantén este flujo de trabajo agnóstico al proyecto. Infiere comandos de verificación y estructura del repositorio; no codifiques nombres de aplicaciones o paquetes.
• Devuelve la URL del PR cuando hayas terminado.

Prefijos de commit convencionales

Usa Commits Convencionales de nivel profesional. Elige un tipo principal:

Prefijo	Cuándo usar
feat	Nueva capacidad orientada al usuario
fix	Corrección de error
refactor	Reestructuración interna sin cambio de comportamiento previsto
perf	Mejora de rendimiento
chore	Mantenimiento, herramientas, dependencias, tareas domésticas
docs	Solo documentación
test	Solo pruebas
ci	Configuración de CI / pipelines
build	Cambios en el sistema de compilación o bundler
style	Cambios de formato / limpieza impulsada por linter sin cambios lógicos
revert	Revertir un commit anterior

Formato:

tipo(ámbito-opcional): resumen en imperativo

Cuerpo opcional: por qué existe este cambio (1–2 oraciones).

Ejemplos: feat(auth): add refresh token rotation, fix: prevent double-submit on checkout, chore: bump lint config.

Flujo de trabajo

1. Inspeccionar (ejecutar en paralelo)

• git status
• git diff y git diff --staged
• git branch -vv (rama actual + seguimiento)
• git log -8 --oneline (estilo de los mensajes)
• Rama base predeterminada (main preferida, si no master o la predeterminada del repositorio)
• Estado de sincronización remota (git status -sb, commits sin enviar)

Si no hay nada que commitear y no hay commits sin enviar relevantes para este trabajo, detente. No abras un PR vacío.

2. Asegurar la rama correcta

Objetivo: llevar el trabajo a una rama de características dedicada basada en la base más reciente.

1. Determina si la rama actual está destinada a estos cambios:

   • Sí si ya es una rama descriptiva de tema para este trabajo (feat/…, fix/…, chore/… o que coincida claramente con la intención del cambio) y no es la rama predeterminada.
   • No si estás en main/master/predeterminada, una rama de tema no coincidente, una rama no relacionada desactualizada, o HEAD independiente.

2. Si la rama actual no está destinada a estos cambios:

   • Si el árbol de trabajo está sucio, guarda (stash) con un mensaje claro (por defecto; no preguntes a menos que el stash sea imposible).
   • git checkout <base>
   • git pull --ff-only (o actualización equivalente fast-forward desde el remoto de seguimiento)
   • Crea y cambia a una nueva rama descriptiva, p.ej. feat/tema-corto, fix/tema-corto, chore/tema-corto
   • git stash pop en la nueva rama; resuelve conflictos si los hay.

3. Si la rama actual sí está destinada a estos cambios:

   • Permanece en ella.
   • Antes de commitear, actualiza desde la base cuando sea necesario (rebase o merge desde la base más reciente según las normas del repositorio; prefiere opciones no destructivas; no hagas force-push a menos que el usuario lo solicite explícitamente).

Nunca construyas un PR directamente desde la rama predeterminada.

3. Hacer commit

• Prefiere un solo commit coherente a menos que el usuario haya solicitado una división.
• El mensaje usa un prefijo convencional adecuado y un resumen en imperativo.
• Cuerpo (opcional): enfócate en el por qué, no en una lista de archivos.
• Después del commit, ejecuta git status para confirmar el estado esperado.
• Si un hook falla: corrige el problema y crea un nuevo commit. No hagas amend a menos que las reglas de amend estén completamente cumplidas.

4. Hacer push

git push -u origin HEAD

Solicita los permisos necesarios cuando el sandbox/red/gh bloquee la operación.

5. Abrir el PR

Analiza todos los commits que se fusionarán en la base (no solo el último).

Título: el mismo espíritu que el resumen del commit — claro, específico, convencional cuando ayude. Sin títulos vagos.

Plantilla del cuerpo (requerida):

## Resumen

- 2–5 viñetas sobre qué se envía y por qué es importante

## Por qué

- Problema, motivación o detonante de este cambio

## Qué cambió

- Viñetas agrupadas por área (comportamiento, API/contratos, datos, UI, infraestructura, pruebas, documentación)
- Menciona explícitamente cambios disruptivos, migraciones o cambios en el comportamiento de auth/sesión

## Arquitectura / flujo

Incluye al menos uno:

1. Diagrama Mermaid (secuencia, diagrama de flujo o estado) para la ruta principal
2. Diagrama ASCII para estructura, capas o antes → después

Usa Mermaid para flujo de control; ASCII para árboles o mapas de capas.
Los diagramas deben coincidir con el diff real — no inventes arquitectura.

## Riesgo / reversión

- Posibles modos de fallo
- Notas sobre reversión segura / mitigación

## Plan de pruebas

- [ ] Pasos concretos que un revisor pueda ejecutar
- [ ] Comandos de verificación apropiados para el repositorio, descubiertos desde el proyecto

Crea con gh pr create y un cuerpo HEREDOC. Establece --base explícitamente cuando sea necesario.

6. Informar

Mantenlo breve:

• nombre de la rama
• resumen del commit
• título del PR
• URL del PR
• archivos intencionalmente sin commit