Desplegar en Vercel

Despliega cualquier proyecto en Vercel. Siempre despliega como vista previa (no producción) a menos que el usuario pida explícitamente producción.

El objetivo es llevar al usuario a la mejor configuración a largo plazo: su proyecto vinculado a Vercel con despliegues automáticos mediante git push. Cada método a continuación intenta acercar al usuario a ese estado.

Paso 1: Recopilar el estado del proyecto

Ejecuta las cuatro comprobaciones antes de decidir qué método usar:

# 1. Verifica si hay un remote git
git remote get-url origin 2>/dev/null

# 2. Verifica si está vinculado localmente a un proyecto de Vercel (cualquier archivo significa vinculado)
cat .vercel/project.json 2>/dev/null || cat .vercel/repo.json 2>/dev/null

# 3. Verifica si el CLI de Vercel está instalado y autenticado
vercel whoami 2>/dev/null

# 4. Lista los equipos disponibles (si está autenticado)
vercel teams list --format json 2>/dev/null

Selección de equipo

Si el usuario pertenece a varios equipos, presenta todos los slugs de equipo disponibles como una lista con viñetas y pregunta a cuál desplegar. Una vez que el usuario elija un equipo, procede inmediatamente al siguiente paso — no pidas confirmación adicional.

Pasa el slug del equipo mediante --scope en todos los comandos posteriores del CLI (vercel deploy, vercel link, vercel inspect, etc.):

vercel deploy [path] -y --no-wait --scope <team-slug>

Si el proyecto ya está vinculado (existe .vercel/project.json o .vercel/repo.json), el orgId en esos archivos determina el equipo — no es necesario preguntar de nuevo. Si solo hay un equipo (o solo una cuenta personal), omite la pregunta y úsalo directamente.

Acerca del directorio .vercel/: Un proyecto vinculado tiene:

.vercel/project.json — creado por vercel link (vinculación de proyecto único). Contiene projectId y orgId.
.vercel/repo.json — creado por vercel link --repo (vinculación basada en repositorio). Contiene orgId, remoteName y un array projects que mapea directorios a IDs de proyectos de Vercel.

Cualquiera de los dos archivos significa que el proyecto está vinculado. Verifica ambos.

NO uses vercel project inspect, vercel ls o vercel link para detectar el estado en un directorio no vinculado — sin un archivo de configuración .vercel/, estos comandos mostrarán un prompt interactivo (o con --yes, vincularán silenciosamente como efecto secundario). Solo vercel whoami es seguro de ejecutar en cualquier lugar.

Paso 2: Elegir un método de despliegue

Vinculado (`.vercel/` existe) + tiene remote git → Git Push

Este es el estado ideal. El proyecto está vinculado y tiene integración con git.

Pregunta al usuario antes de hacer push. Nunca hagas push sin aprobación explícita:

Este proyecto está conectado a Vercel mediante git. Puedo hacer commit y push para
activar un despliegue. ¿Quieres que proceda?

Haz commit y push:
```
git add .
git commit -m "deploy: <descripción de los cambios>"
git push
```
Vercel construye automáticamente a partir del push. Las ramas que no son de producción obtienen despliegues de vista previa; la rama de producción (normalmente main) obtiene un despliegue de producción.
Recupera la URL de vista previa. Si el CLI está autenticado:
```
sleep 5
vercel ls --format json
```
La salida JSON tiene un array deployments. Encuentra la entrada más reciente — su campo url es la URL de vista previa.

Si el CLI no está autenticado, dile al usuario que revise el panel de control de Vercel o los checks de estado de commit en su proveedor de git para la URL de vista previa.

Vinculado (`.vercel/` existe) + sin remote git → `vercel deploy`

El proyecto está vinculado pero no hay repositorio git. Despliega directamente con el CLI.

vercel deploy [path] -y --no-wait

Usa --no-wait para que el CLI regrese inmediatamente con la URL del despliegue en lugar de bloquear hasta que la compilación termine (las compilaciones pueden tardar). Luego verifica el estado del despliegue con:

vercel inspect <deployment-url>

Para despliegues de producción (solo si el usuario lo pide explícitamente):

vercel deploy [path] --prod -y --no-wait

No vinculado + CLI autenticado → Vincular primero, luego desplegar

El CLI funciona pero el proyecto aún no está vinculado. Esta es la oportunidad para llevar al usuario al mejor estado.

Pregunta al usuario a qué equipo desplegar. Presenta los slugs de equipo del Paso 1 como una lista con viñetas. Si solo hay un equipo (o solo una cuenta personal), omite este paso.

Una vez seleccionado un equipo, procede directamente a vincular. Dile al usuario lo que sucederá, pero no pidas confirmación por separado:

Vinculando este proyecto a <nombre del equipo> en Vercel. Esto creará un proyecto
en Vercel para desplegar y habilitará despliegues automáticos en futuros pushes de git.

Si existe un remote git, usa vinculación basada en repositorio con el ámbito del equipo seleccionado:
```
vercel link --repo --scope <team-slug>
```
Esto lee la URL del remote git y la empareja con proyectos existentes de Vercel que se despliegan desde ese repositorio. Crea .vercel/repo.json. Esto es mucho más confiable que vercel link (sin --repo), que intenta emparejar por nombre de directorio y a menudo falla cuando la carpeta local y el proyecto de Vercel tienen nombres diferentes.

Si no hay remote git, recurre a la vinculación estándar:
```
vercel link --scope <team-slug>
```
Esto le pide al usuario que seleccione o cree un proyecto. Crea .vercel/project.json.
Luego despliega usando el mejor método disponible:
- Si existe un remote git → haz commit y push (ver método git push arriba)
- Si no hay remote git → vercel deploy [path] -y --no-wait --scope <team-slug>, luego vercel inspect <url> para verificar el estado

No vinculado + CLI no autenticado → Instalar, autenticar, vincular, desplegar

El CLI de Vercel no está configurado en absoluto.

Instala el CLI (si aún no está instalado):
```
npm install -g vercel
```
Autentica:
```
vercel login
```
El usuario completa la autenticación en su navegador. Si se ejecuta en un entorno no interactivo donde no es posible iniciar sesión, pasa al respaldo sin autenticación más abajo.
Pregunta a qué equipo desplegar — presenta los slugs de equipo de vercel teams list --format json como una lista con viñetas. Si solo hay un equipo / cuenta personal, omite. Una vez seleccionado, procede inmediatamente.

Vincula el proyecto con el ámbito del equipo seleccionado (usa --repo si existe un remote git, o vercel link simple en caso contrario):

vercel link --repo --scope <team-slug>   # si existe remote git
vercel link --scope <team-slug>          # si no hay remote git

Despliega usando el mejor método disponible (git push si existe remote, de lo contrario vercel deploy -y --no-wait --scope <team-slug>, luego vercel inspect <url> para verificar el estado).

Respaldo sin autenticación — sandbox de claude.ai

Cuándo usarlo: Último recurso cuando el CLI no se puede instalar o autenticar en el sandbox de claude.ai. Esto no requiere autenticación — devuelve una URL de vista previa (sitio en vivo) y una URL de reclamo (transfiere a tu cuenta de Vercel).

bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh [path]

Argumentos:

path - Directorio a desplegar, o un archivo .tgz (por defecto el directorio actual)

Ejemplos:

# Desplegar el directorio actual
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh

# Desplegar un proyecto específico
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /path/to/project

# Desplegar un tarball existente
bash /mnt/skills/user/deploy-to-vercel/resources/deploy.sh /path/to/project.tgz

El script detecta automáticamente el framework desde package.json, empaqueta el proyecto (excluyendo node_modules, .git, .env), lo sube y espera a que la compilación termine.

Dile al usuario: "Tu despliegue está listo en [previewUrl]. Reclámalo en [claimUrl] para gestionar tu despliegue."

Respaldo sin autenticación — sandbox de Codex

Cuándo usarlo: En el sandbox de Codex donde el CLI puede no estar autenticado. Codex se ejecuta en un entorno limitado por defecto — prueba el CLI primero y recurre al script de despliegue si falla la autenticación.

Verifica si el CLI de Vercel está instalado (no se necesita escalación para esta verificación):
```
command -v vercel
```
Si vercel está instalado, intenta desplegar con el CLI:
```
vercel deploy [path] -y --no-wait
```

Si vercel no está instalado, o el CLI falla con "No se encontraron credenciales existentes", usa el script de respaldo:

skill_dir="<ruta-hacia-el-skill>"

# Desplegar el directorio actual
bash "$skill_dir/resources/deploy-codex.sh"

# Desplegar un proyecto específico
bash "$skill_dir/resources/deploy-codex.sh" /path/to/project

# Desplegar un tarball existente
bash "$skill_dir/resources/deploy-codex.sh" /path/to/project.tgz

El script maneja la detección del framework, el empaquetado y el despliegue. Espera a que la compilación termine y devuelve JSON con previewUrl y claimUrl.

Dile al usuario: "Tu despliegue está listo en [previewUrl]. Reclámalo en [claimUrl] para gestionar tu despliegue."

Acceso de red escalado: Solo escala el comando de despliegue real si el sandbox bloquea la llamada de red (sandbox_permissions=require_escalated). No escales la verificación command -v vercel.

Notas específicas por agente

Claude Code / agentes de terminal

Tienes acceso completo al shell. NO uses la ruta /mnt/skills/. Sigue el flujo de decisión anterior usando el CLI directamente.

Para el respaldo sin autenticación, ejecuta el script de despliegue desde la ubicación instalada del skill:

bash ~/.claude/skills/deploy-to-vercel/resources/deploy.sh [path]

La ruta puede variar según dónde haya instalado el usuario el skill.

Entornos limitados (claude.ai)

Probablemente no puedas ejecutar vercel login ni git push. Ve directamente al respaldo sin autenticación — sandbox de claude.ai.

Codex

Codex se ejecuta en un sandbox. Primero verifica si el CLI está disponible, luego recurre al script de despliegue. Ve al respaldo sin autenticación — sandbox de Codex.

Salida

Siempre muestra al usuario la URL del despliegue.

Git push: Usa vercel ls --format json para encontrar la URL de vista previa. Si el CLI no está autenticado, dile al usuario que revise el panel de control de Vercel o los checks de estado de commit.
CLI deploy: Muestra la URL devuelta por vercel deploy --no-wait. Usa vercel inspect <url> para verificar el estado de la compilación e informar al usuario.

Respaldo sin autenticación: Muestra tanto la URL de vista previa como la URL de reclamo:

¡Despliegue exitoso!

URL de vista previa: https://my-app-abc123.vercel.app
URL de reclamo:      https://vercel.com/claim-deployment?code=...

Visita tu sitio en la URL de vista previa.
Para transferir este despliegue a tu cuenta de Vercel, visita la URL de reclamo.

No hagas curl ni fetch a la URL desplegada para verificar que funciona. Solo devuelve el enlace.

Solución de problemas

Error de salida de red (claude.ai)

Si el despliegue falla debido a restricciones de red en claude.ai, dile al usuario:

El despliegue falló debido a restricciones de red. Para solucionarlo:

1. Ve a https://claude.ai/settings/capabilities
2. Agrega *.vercel.com a los dominios permitidos
3. Intenta desplegar de nuevo

Acceso de red escalado (Codex / entornos limitados)

Si el despliegue falla debido a problemas de red (timeouts, errores DNS, reinicios de conexión) en un entorno limitado, vuelve a ejecutar con permisos escalados (sandbox_permissions=require_escalated). No escales la verificación inicial de disponibilidad del CLI — solo escala el comando de despliegue real.

Ejemplo de orientación al usuario:

El despliegue necesita acceso de red escalado para desplegar en Vercel. Puedo volver a ejecutar
el comando con permisos escalados — ¿quieres que proceda?

Fallo de autenticación del CLI

Si vercel login o vercel deploy falla con errores de autenticación, recurre al script de despliegue sin autenticación (variante claude.ai o Codex, según el entorno).

PhuongDeveloper/landingpage

¿Qué es landingpage?

Preguntar en tu IA favorita

Documentación