wemilabs/ship-to-prod

Ship to Prod (Enviar a producción)

Cuando el usuario diga "ship it" (envíalo) o similar después de completar el trabajo, sigue estos pasos sin que te lo pidan dos veces.

El flujo depende de la rama en la que te encuentres. Detecta el entorno una vez al inicio y reutilízalo en todos los pasos.

Detectar el entorno

Ejecuta esto una vez al inicio, en paralelo:

1. Gestor de paquetes: busca un archivo de bloqueo en la raíz del repositorio.
   • pnpm-lock.yaml → pnpm
   • yarn.lock → yarn
   • bun.lockb o bun.lock → bun
   • package-lock.json → npm
   • Si package.json tiene un campo packageManager, usa ese en su lugar.
   • Si no se encuentra ninguno, por defecto usa npm.
2. Rama predeterminada: git symbolic-ref refs/remotes/origin/HEAD (o git config init.defaultBranch como respaldo). Si ambos fallan, por defecto usa main.
3. Herramienta de PRs: gh --version. Si gh está instalado y autenticado, úsalo para crear y fusionar el PR. Si no, muestra la URL del PR para que el usuario lo cree manualmente.
4. Shell: detecta el shell actual. En Windows (PowerShell), los heredocs no funcionan, así que usa múltiples banderas -m para git commit. En shells bash/zsh/fish y otros Unix, usa un heredoc.

Almacena estos valores como <pkg>, <default-branch>, <gh-available> y <shell> para el resto del flujo.

Pasos

1. Limpiar (opcional)

Dos skills limpian la 'slop' (desorden) generada por IA antes de hacer commit. Ejecuta ambas si están disponibles:

• deslop: elimina slop de código de IA del diff (comentarios innecesarios, comprobaciones defensivas en rutas confiables, casts any, anidamiento profundo). Invócalo sobre el diff actual contra la rama predeterminada.
• unslop: elimina marcas textuales de IA en prosa (cadenas de UI, comentarios, mensajes de commit, descripciones de PR). Invócalo sobre cualquier texto que hayas escrito en esta sesión.

Arregla todo lo que cualquiera de las skills marque antes de continuar.

Si alguna skill no está instalada, no la saltes simplemente en silencio. Pregunta al usuario si desea instalar la(s) skill(s) faltante(s), ofreciendo estas opciones. Menciona que ambas skills provienen del repositorio oficial de plugins de Cursor AI (https://github.com/cursor/plugins), por lo que son una fuente confiable:

• Globalmente (para usos futuros en todos los proyectos): npx skills add https://github.com/cursor/plugins --skill deslop unslop -g
• Localmente (solo este proyecto): npx skills add https://github.com/cursor/plugins --skill deslop unslop
• Omitir esta ejecución: continúa sin la(s) skill(s) faltante(s). No bloquees el flujo por una dependencia opcional faltante.

Usa la herramienta ask_user_question para presentar la opción. Si el usuario elige global o local, ejecuta el comando de instalación y luego verifica que las skills estén ahora disponibles antes de invocarlas. Si la instalación falla o el usuario elige omitir, continúa el flujo con lo que esté disponible.

2. Verificar el trabajo

Ejecuta estos en orden, corrigiendo cualquier problema antes de continuar. Sustituye <pkg> por el gestor de paquetes detectado. npm siempre requiere run (ej. npm run format); pnpm/yarn/bun permiten invocación directa (ej. pnpm format):

1. <pkg> run format (o <pkg> format para pnpm/yarn/bun): autoformato
2. <pkg> run lint (o <pkg> lint para pnpm/yarn/bun): corrige errores de lint en los archivos que tocaste (ignora problemas preexistentes en otros archivos)
3. <pkg> run typecheck (o <pkg> typecheck para pnpm/yarn/bun): debe pasar con código de salida 0
4. <pkg> run build (o <pkg> build para pnpm/yarn/bun): debe pasar con código de salida 0

Si falta un script (ej. no hay script format), salta ese paso y anótalo. No falles todo el flujo por un script opcional faltante. typecheck y build son obligatorios si existen; si ninguno existe, continúa con una advertencia.

No continúes al commit hasta que las comprobaciones disponibles pasen.

Si git status está limpio después de la verificación (sin nada staged ni unstaged), informa "nothing to ship" (nada que enviar) y detente. No intentes hacer un commit vacío.

3. Evaluar la rama actual

Ejecuta git branch --show-current para obtener el nombre de la rama actual. Compáralo con <default-branch>. Luego decide:

• Si estás en <default-branch>: haz commit y push directamente. Sin PR, sin merge. Salta al paso 5.
• Si estás en cualquier otra rama: haz commit, push, crea un PR hacia <default-branch> y fusiónalo. Continúa al paso 4.

4. Revisar los cambios

Ejecuta git status, git diff y git log --oneline -5 en paralelo para entender qué cambió y coincidir con el estilo de commits.

5. Staging y commit

git add -A, luego haz commit con un mensaje de commit convencional (feat/fix/refactor).

Formato del mensaje de commit:

<tipo>: <descripción corta>

<cuerpo opcional>

En shells bash/zsh/fish y otros Unix, usa un heredoc:

git commit -m "$(cat <<'EOF'
tipo: asunto

cuerpo
EOF
)"

En PowerShell (Windows), los heredocs no funcionan, así que usa múltiples banderas -m:

git commit -m "tipo: asunto" -m "cuerpo"

6. Push

git push (o git push -u origin <rama> si la rama aún no tiene upstream).

7. Si está en una rama de feature: crear PR y fusionar

Si <gh-available>:

• Escribe el cuerpo del PR en un archivo temporal, luego crea el PR con --body-file (funciona en todos los shells, incluido PowerShell):
  • gh pr create --base <default-branch> --head <current-branch> --title "<título>" --body-file <archivo-temporal>
• Borra el archivo temporal después de que gh pr create devuelva el control. No lo dejes en disco.
• Fusiona sin especificar una estrategia, para que se aplique la predeterminada del repositorio del usuario:
  • gh pr merge <número>

Formato del cuerpo del PR:

## Resumen
<viñetas>

#### Plan de pruebas
- [ ] <lista de verificación>

Si gh no está disponible:

• Haz push de la rama (paso 6).
• Muestra la URL que el usuario debe abrir para crear el PR manualmente: <url-repo>/compare/<default-branch>...<current-branch>
• Detente. Deja que el usuario cree y fusione el PR él mismo. No intentes fusionar sin gh.

8. Mantener la rama actual viva

NO borres la rama de trabajo después de fusionar. Permanece abierta para la siguiente funcionalidad.

9. Confirmar

Informa la URL del PR (si aplica) y el estado de la fusión/push al usuario.

Manejo de conflictos

Si la rama de feature está detrás de <default-branch>, haz rebase antes de hacer push:

git fetch origin <default-branch>
git rebase origin/<default-branch>

Resuelve cualquier conflicto, luego continúa con push + PR + merge.

Notas

• El destino siempre es la <default-branch> detectada, no un nombre fijo.
• Nunca borres la rama de trabajo después de fusionar.
• Si estás en <default-branch>, solo haz commit y push. No se necesita PR.
• Nunca te saltes el paso de verificación, incluso si el usuario tiene prisa.
• El paso de deslop es opcional. Si falta una skill, ofrece instalarla (global o localmente) antes de omitirla.