← Volver

Deploy Check

Esta habilidad automatiza una lista de verificación pre-despliegue exhaustiva, verificando el estado de la compilación, los resultados de las pruebas, el linting, las variables de entorno, la configuración de Vercel, las migraciones de Supabase y el estado del repositorio Git. Asegura que tu proyecto cumpla con los criterios de preparación antes del despliegue.

Qué hace

La habilidad deploy-check proporciona una lista de verificación automatizada previa al despliegue. Verifica sistemáticamente la preparación de tu proyecto revisando el proceso de compilación, ejecutando pruebas, analizando resultados de linting, validando variables de entorno, inspeccionando la configuración de Vercel y detectando migraciones pendientes de Supabase. También evalúa el estado de tu repositorio Git, señalando cambios no confirmados o ramas no actualizadas.

Cuándo usarlo

Debes usar esta habilidad antes de cada despliegue a entornos de producción o staging. Ayuda a prevenir problemas comunes de despliegue identificando bloqueadores temprano, como compilaciones fallidas, pruebas rotas, variables de entorno faltantes o migraciones de base de datos no confirmadas. Esto asegura un proceso de despliegue más fiable y consistente.

Cómo configurarlo

Para configurar esta habilidad, copia el archivo de definición SKILL.md en tu repositorio en .claude/skills/deploy-check/SKILL.md. Una vez que el archivo esté en su lugar, puedes invocar la habilidad escribiendo /deploy-check en Claude Code.

El contenido

Pre-Deployment Check

Run all checks before deploying. Fail fast on any blocker.

Environment: $ARGUMENTS (default: production) Current branch: !git branch --show-current Uncommitted changes: !git status --short Last commit: !git log --oneline -1 Package manager: ![ -f bun.lockb ] && echo "bun" || ([ -f pnpm-lock.yaml ] && echo "pnpm" || ([ -f yarn.lock ] && echo "yarn" || echo "npm"))

Step 1: Git State

Verify clean git state:

  • No uncommitted changes (warn if working tree is dirty)
  • Current branch is main or a release branch (warn if on feature branch)
  • Branch is up to date with remote: git fetch origin && git rev-list HEAD..origin/main --count

If uncommitted changes exist: WARN but continue. If behind remote: BLOCK.

Step 2: Build

Run the project build:

npm run build 2>&1 || exit 1

Replace npm with the detected package manager. If the build fails: BLOCK.

Step 3: Type Check

If tsconfig.json exists:

npx tsc --noEmit 2>&1

If type errors exist: BLOCK.

Step 4: Lint

If a lint script exists in package.json:

npm run lint 2>&1

If lint errors exist: WARN (not blocking unless errors, warnings are OK).

Step 5: Tests

Run the test suite:

npm run test -- --run 2>&1 || npx vitest run 2>&1

If tests fail: BLOCK.

Step 6: Environment Variables

Check that all required env vars are set:

  1. Read .env.local.example or .env.example to get the list of required variables
  2. Check each variable exists in .env.local or .env.production
  3. Flag any missing variables

Verify the framework's public Supabase vars are set:

  • Next (default): NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY
  • Vite exception: VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY

Missing env vars: BLOCK.

Step 7: Vercel Configuration

Check Vercel setup:

  1. Check Vercel config — Next is zero-config (no vercel.json rewrite needed); Vite-exception repos need vercel.json with the SPA index.html rewrite
  2. Check if .vercel/project.json exists (indicates vercel link was run)
  3. Run vercel whoami 2>/dev/null to verify CLI login

Missing Vercel link: WARN — remind to run vercel link. Vercel CLI not logged in: WARN — remind to run vercel login.

Step 8: Pending Migrations

If supabase/migrations/ exists:

  • Check for migration files not yet applied: supabase migration list 2>/dev/null
  • Check for uncommitted migration files in the directory

Unapplied migrations: WARN — remind to run supabase db push after deploy.

Step 9: Bundle Size (optional)

After build, measure the output (Next: .next/; Vite exception: dist/):

du -sh .next/ dist/ 2>/dev/null

Report total build output size. Flag if over 5MB: WARN.

Step 10: SEO & GEO Gate

Only if the project has a public content surface (skip for behind-auth-only tools / Vite-exception SPAs with a documented exemption in CLAUDE.md). Verify against ref/growth/seo.md and ref/growth/geo.md:

SEO:

  • Sitemap + robots generated from code (Next: app/sitemap.ts + app/robots.ts; Vite: scripts/generate-sitemap.mjs + committed public/sitemap.xml + drift check)
  • Robots references the sitemap and disallows the §7.4 route categories
  • SEO/content routes server-rendered/SSG/ISR — not client-only

GEO:

  • robots declares an explicit, correct AI-crawler policy — retrieval bots (OAI-SearchBot, Claude-SearchBot, PerplexityBot, Googlebot) allowed; no accidental blanket Disallow for AI bots
  • content pages answer-first + citability signals (sourced/dated stats, quotable claims)
  • on-site entity hooks: Organization+sameAs, named author, visible dateModified
  • GEO measurement wired (passive AI-referral + a defined active prompt set)

Client-only content rendering, missing sitemap/robots, or an AI-crawler policy that accidentally blocks retrieval bots on a public content product: BLOCK. Missing answer-first structure / citability / entity hooks / measurement: WARN. GEO structured-data types (FAQPage/QAPage), Bing/IndexNow, off-site presence: WARN (SHOULD). /llms.txt: check ONLY for products with a public API/developer-docs surface — it is NOT a visibility signal; its absence on a marketing site is not a finding. For a .lovable. repo: treat all GEO items as WARN (SPA limit accepted).

For a deep pass or to fix findings, run /optimize-growth optimize.

Step 11: Summary

## Deploy Check Results

Branch: <branch> (<clean/dirty>)
Remote: <up to date / N commits behind>

| Check            | Status              |
|------------------|---------------------|
| Build            | PASS / FAIL         |
| Type Check       | PASS / FAIL / SKIP  |
| Lint             | PASS / WARN / SKIP  |
| Tests            | PASS / FAIL / SKIP  |
| Env Vars         | PASS / MISSING: ... |
| Vercel Config    | PASS / WARN         |
| Supabase Link    | PASS / WARN / SKIP  |
| Migrations       | PASS / PENDING: ... |
| Bundle Size      | <size> (OK / WARN)  |
| SEO Gate         | PASS / BLOCK / SKIP |
| GEO Gate         | PASS / WARN / BLOCK / SKIP |

### Verdict
READY TO DEPLOY / BLOCKED (fix issues above first)

### Blockers
- <list of blocking issues, if any>

### Warnings
- <list of non-blocking warnings, if any>

### Deployment
Vercel auto-deploys on push to main. To trigger manually:
- Preview: `vercel`
- Production: `vercel --prod`

Viene directamente del framework con el que se construye este sitio. Esta página muestra siempre la versión actual.

¿Quieres algo así para ti?

Empieza con una conversación: 30 minutos, sin compromiso.