# Publicar > Lleva tu app o agente de IA (Next.js + Supabase) desde tu computadora hasta una URL de producción que RESPONDE — sin el bucle de parches. Diagnostica la causa raíz, la arregla sola, vuelve a desplegar y valida en vivo en un loop que no se detiene hasta lograrlo. Es el 5º y último paso del flujo de calidad (después de validar y auditar). Activar cuando el usuario dice: /publicar, quiero publicar m… - **Type:** Skill - **Install:** `agentstack add skill-lalakinskywalker-bluntag-claude-skills-publicar` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [LalakinSkywalker](https://agentstack.voostack.com/s/lalakinskywalker) - **Installs:** 0 - **Category:** [Databases](https://agentstack.voostack.com/c/databases) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [LalakinSkywalker](https://github.com/LalakinSkywalker) - **Source:** https://github.com/LalakinSkywalker/bluntag-claude-skills/tree/master/.claude/skills/publicar ## Install ```sh agentstack add skill-lalakinskywalker-bluntag-claude-skills-publicar ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # /publicar — De tu compu a producción, sin el bucle de parches > "El build que pasa no es el objetivo. El objetivo es que un usuario real abra la URL y la app le responda." Esta skill resuelve el dolor más común de quien construye con la SaaS Factory: **tu app funciona perfecto en tu computadora (`localhost`), la subes a Vercel, y truena** — el build falla, o peor: el build pasa pero la app responde con "Error de conexión" cuando alguien la usa. Aplicas un ajuste para que el build pase, y eso rompe la funcionalidad. Aplicas otro, y rompe algo distinto. Es un **bucle de parches** sin salida. Esta skill rompe ese bucle. No te da una lista de comandos: **toma tu app (sana o rota), encuentra la causa raíz de lo que la detiene, la arregla, vuelve a desplegar, y comprueba en vivo que responde** — y si no responde, lo intenta de otra forma, sin detenerse, hasta dejarla viva. --- ## Dónde encaja `/publicar` (el 5º paso) `/publicar` hace UNA cosa y la hace hasta el final: **el deploy**. No corre auditorías ni revisiones — eso es trabajo de sus skills hermanas, cada una con su momento: | Momento | Skill | Pregunta que responde | |---|---|---| | Durante cada sesión | `/save-status` | "¿Si esto se corta, puedo retomar sin perder nada?" | | Antes de publicar | `/validacion-visual` | "¿Los flujos de mi app jalan sin bugs visibles?" | | Antes de publicar | `/auditoria-profunda` | "¿La app respeta lo que el usuario configura?" | | Antes de publicar | `/auditoria-de-seguridad` | "¿Un atacante puede romper los candados?" | | Antes de publicar | `/auditoria-performance` | "¿La app es ágil o desespera al usuario?" | | **El último paso** | **`/publicar`** | **"¿Mi app responde VIVA en su URL de producción?"** | Usa las que tu flujo pida — `/publicar` no te impone ninguna. Pero el orden sano es: valida primero, publica al final. Esta skill arranca directo en el deploy y asume que tu app ya pasó las revisiones que TÚ decidiste hacerle. **Stack objetivo:** Next.js (App Router) + Supabase + un modelo de IA (Vercel AI SDK / OpenRouter / SDK directo), desplegado en **Vercel** (el Golden Path de la SaaS Factory). Para casos que NO encajan en serverless, la skill lo **detecta y te lo explica** (ver Familia 7), pero no ejecuta el despliegue en VPS. --- ## Cuándo se activa - Invocación directa: `/publicar` - "Quiero publicar mi app" / "lanza mi app" / "sube mi app a internet" - "No me sube a Vercel" / "el deploy falla" - "En local jala pero en producción truena / da Error de conexión" - "El build pasa pero la app no responde" - "Mi agente de IA funciona en mi compu pero en Vercel no contesta" - "Llévame esto a producción" / "deploya mi app" --- ## El principio que lo cambia todo La mayoría de la gente valida el deploy preguntando *"¿cargó el build?"*. Eso es mentira: **un build verde no significa que tu app funcione**. El caso real reportado en la comunidad (y que vive media comunidad) es exactamente ese: el build pasa, pero el agente da "Error de conexión" cuando procesa una consulta real. Por eso esta skill define el éxito de UNA sola forma: > **OBJETIVO FIJO:** un endpoint REAL de la app (no el home estático — el flujo que importa: el chat, la consulta, la acción del agente) responde **correctamente** desde la **URL de producción**, ejecutado como lo ejecutaría un usuario. Mientras eso no pase, el trabajo NO está hecho. Da igual cuántos builds verdes haya. --- ## EL MOTOR DE LOOP (corazón de la skill) Es un bucle con **objetivo fijo** que no se detiene hasta cumplirlo o hasta agotar el presupuesto de intentos. Hereda la mecánica de auto-blindaje del `bucle-agentico` de Bluntag (mapear → arreglar → documentar → repetir) pero con una diferencia clave: aquí el objetivo no es "completar fases", es **"la URL de producción responde bien"**, y cada vuelta del loop ataca la **causa raíz**, nunca el síntoma. ``` ┌─────────────────────────────────────────────┐ │ OBJETIVO FIJO: el endpoint real responde │ │ correctamente en la URL de produccion │ └─────────────────────────────────────────────┘ │ ┌───────────────────▼───────────────────┐ ┌────────────▶│ 1. MAPEAR (estado real del proyecto) │ │ └───────────────────┬────────────────────┘ │ ▼ │ ┌────────────────────────────────────────┐ │ │ 2. DIAGNOSTICAR (¿que familia de falla │ │ │ del catalogo es? causa raiz, no │ │ │ sintoma) │ │ └───────────────────┬────────────────────┘ │ ▼ │ ┌────────────────────────────────────────┐ │ │ 3. ARREGLAR la causa raiz │ │ └───────────────────┬────────────────────┘ │ ▼ │ ┌────────────────────────────────────────┐ │ │ 4. RE-DESPLEGAR + VALIDAR EN VIVO │ │ │ (curl/Playwright al endpoint real │ │ │ en la URL de prod) │ │ └───────────────────┬────────────────────┘ │ ▼ │ ¿Responde bien? │ ┌─────────┴─────────┐ │ NO SI │ │ │ │ ┌─────────▼────────┐ ┌──────▼───────────────┐ └─────────│ 5. AUTO-BLINDAJE │ │ CIERRE: reporte + │ (otra │ documentar el │ │ URL viva │ vuelta) │ aprendizaje; │ └──────────────────────┘ │ ¿misma falla 2x? │ │ cambia hipotesis │ └──────────────────┘ ``` ### Reglas del motor 1. **Una hipótesis a la vez.** Diagnostica UNA causa raíz, arréglala, re-valida. No apliques 5 cambios juntos: si funciona no sabrás cuál fue, y si rompe tampoco. 2. **Causa raíz, no síntoma.** "Error de conexión" es un síntoma. La causa puede ser runtime Edge, env var ausente, CSP, o RLS. La skill identifica CUÁL antes de tocar nada. Parchear el síntoma es lo que genera el bucle infinito. 3. **Valida el flujo real, no el home.** Después de cada deploy, ejecuta el endpoint que importa (el chat, la consulta del agente) contra la URL de producción — no te conformes con que cargue la página. 4. **Tope de iteraciones: 8 vueltas.** Si tras 8 intentos no converge, PARA y entrega un reporte honesto: qué se probó, qué se descartó, cuál es la hipótesis más probable, y si el caso amerita VPS (Familia 7). Nunca finjas éxito. 5. **Misma falla 2 veces seguidas → cambia de hipótesis.** Si el mismo error reaparece tras un fix, el diagnóstico estaba mal: vuelve al paso 2 con otra familia del catálogo. 6. **Auto-blindaje en cada fix.** Cada causa raíz nueva que encuentres se documenta en la sección "Aprendizajes" de abajo, para que la próxima vez se diagnostique en segundos. ### Por qué un motor propio (y no `/goal` ni `bucle-agentico` tal cual) - **`bucle-agentico`** (Bluntag) aporta la columna vertebral: el ciclo mapear→arreglar→documentar→repetir y el auto-blindaje. Pero su objetivo es "completar las fases de un PRP" — abierto. Aquí el objetivo es **único y medible** ("responde en prod"), lo que permite el tope de intentos y el criterio de parada honesto. - **`/goal`** (skill de Anthropic de persecución de objetivo) aporta la idea de un objetivo terminal verificable con criterio de éxito explícito. Tomamos eso: el éxito es una **comprobación externa** (curl/Playwright al endpoint), no la opinión del agente. - **Lo nuestro** combina ambos en un motor específico para deploy: objetivo medible + ciclo de auto-blindaje + catálogo de causas raíz + criterio de parada. No es ninguna de las dos recicladas — es producto propio. (La comparativa detallada vive en `COMPARATIVA-MOTORES.md` de esta skill.) --- ## EL FLUJO COMPLETO (lo que la skill ejecuta) ### Paso 0 — Revisar las herramientas (para que nada te frene a medio camino) Antes de empezar, la skill comprueba su propio entorno y, si falta algo, te guía para instalarlo en palabras claras (qué es, para qué sirve, dónde dar clic): - Que el proyecto sea Next.js y tenga `package.json` sano. - Que exista una cuenta de Vercel conectada (`vercel whoami`); si no, te lleva de la mano por `vercel login` (es gratis empezar). - Que el proyecto esté en git (la red de seguridad para deshacer cualquier cosa). **Regla:** ningún mensaje de este paso asume conocimiento técnico. "Falta X" siempre viene con "X es… y se arregla así…". ### Paso A — MAPEAR el proyecto (antes de tocar nada) Lee el estado real, no supongas: - **Stack y config:** `package.json`, `next.config.{js,ts}`, `vercel.json` (si existe), versiones. - **Runtime de las rutas:** grep de `export const runtime = 'edge'` / `'nodejs'` en `app/api/**` y en server components. (Los SDK de IA y `pg`/Supabase service suelen NO correr en Edge.) - **Uso de variables de entorno:** grep de `process.env.` — lista TODAS las que la app necesita, separa las `NEXT_PUBLIC_*` (cliente) de las privadas (servidor). - **Modelo de IA:** cómo se llama (OpenRouter / Vercel AI SDK / SDK directo), si la key es de pago o gratis, el endpoint del modelo. - **Supabase:** cliente browser vs server vs service_role; dónde se usa cada uno; si hay RLS. - **CSP / headers:** si `next.config` o `vercel.json` definen `Content-Security-Policy`, leer `connect-src` y `media-src`. OJO: si los headers se aplican solo en producción (patrón común), en local no verás el problema. - **El endpoint que importa:** identifica CUÁL ruta es la que el usuario usa (el chat, la consulta del agente) — esa es la que hay que validar en vivo. - **La URL pública real:** la URL canónica del proyecto (`.vercel.app` o el dominio propio), NO la URL del deployment (`-.vercel.app`) — esa última suele dar 401 por la protección "Vercel Authentication" y te hace creer que la app está rota cuando está viva. ### Paso B — DIAGNOSTICAR contra el catálogo Con el mapa, identifica la familia de falla más probable. Ver `CATALOGO-FALLAS.md` (7 familias). El diagnóstico se hace leyendo **evidencia real, nunca adivinando**: - **Build Logs de Vercel** si el build falla. - **Runtime Logs de Vercel** del momento exacto en que truena, si el build pasa pero el endpoint responde mal. - **Consola del navegador** (con Playwright o a mano) si la falla es del lado cliente: las violaciones de CSP, por ejemplo, NO aparecen en los logs de Vercel — solo en la consola del navegador, y la página puede "verse normal" mientras tanto. ### Paso C — ARREGLAR la causa raíz Aplica el fix de la familia diagnosticada. UN cambio. Documenta qué cambiaste y por qué. ### Paso D — RE-DESPLEGAR y VALIDAR EN VIVO - Re-desplegar (commit que dispara Vercel, o `vercel --prod` si el usuario usa CLI). - **Validar el endpoint real** contra la **URL pública de producción** (la canónica, no la del deployment): un `curl`/`fetch` al endpoint del agente con un payload real, o Playwright navegando el flujo. Confirmar respuesta correcta (no 500, no "Error de conexión", la respuesta esperada). - Si la falla era del lado cliente, revisar también la **consola del navegador** después del fix: que no queden violaciones de CSP ni errores silenciosos. - Si responde bien → CIERRE. Si no → Paso E. ### Paso E — AUTO-BLINDAJE y otra vuelta Documenta el aprendizaje, evalúa si la falla cambió (progreso) o es la misma (cambiar hipótesis), y vuelve al Paso B. Respeta el tope de 8 iteraciones. ### CIERRE — Reporte en palabras claras Un solo mensaje, sin jerga: - Qué estaba roto (causa raíz, en palabras claras). - Qué se arregló (el cambio concreto, archivo:línea). - **La URL viva + el endpoint validado** ← compártela. - Si aplica: qué se aprendió (quedó blindado para la próxima). - Si algo NO quedó: se dice con la misma claridad (qué está roto, qué se intentó, cuál es el camino). **Esta skill nunca te dice "todo bien" si no es cierto.** --- ## El catálogo de fallas Las 7 familias de causa raíz viven en `CATALOGO-FALLAS.md` (en esta misma carpeta). Cada una trae: cómo se detecta, cuál es la causa raíz, y cómo se arregla. Es la base de conocimiento que hace el diagnóstico rápido en vez de adivinar. --- ## Reglas duras de esta skill - **Valida el flujo real, no el home.** Es la regla #1. - **Una hipótesis a la vez, causa raíz, no síntoma.** - **Reporte honesto si no converge.** Mejor "no lo resolví, aquí está la hipótesis y probablemente necesitas VPS" que un falso éxito. - **VPS se detecta y explica, NUNCA se ejecuta** (Familia 7). - **Sin secretos en logs, commits ni reportes.** Si un fix toca una key, se referencia por nombre, nunca se imprime el valor. Para cargar secrets a Vercel, usar stdin (`... | vercel env add NOMBRE production`) para que el valor no toque la pantalla. - **Sin push a producción sin autorización explícita del usuario.** - **Cero jerga sin traducción.** Cada término técnico que aparezca en preguntas o reportes va acompañado de su explicación en palabras claras, en el mismo mensaje. - **Cada arreglo se explica en una línea de humano.** El usuario siempre sabe qué se le hizo a su app. - **Ortografía impecable** en todo lo que ve el usuario. --- ## Aprendizajes (auto-blindaje — crece con cada deploy) > Cada causa raíz nueva que esta skill resuelve se documenta aquí para diagnosticarla en segundos la próxima vez. **2026-06-10 — Primera corrida real (app de muestra, Vercel):** - **La URL del deployment NO es la URL pública.** Las URLs tipo `-.vercel.app` que imprime el CLI devuelven **401** por la protección "Vercel Authentication" (activa por default). La URL que ve el usuario real es el alias canónico `.vercel.app`. Validar SIEMPRE contra el alias público, no contra la URL del deployment — si validas contra la protegida, un 401 parece "app rota" cuando en realidad está viva. - **`vercel env add` vía stdin no imprime el valor** (`node -e "...match(...)" | vercel env add NOMBRE production`) — forma segura de cargar secrets sin que toquen pantalla ni logs. Tras cargar, **redeploy obligatorio** (confirmado en vivo: Vercel no relee envs sin deploy nuevo). - **Modelos razonadores (gpt-5/o-series): respuesta VACÍA intermitente** si `max_completion_tokens` es corto — el razonamiento interno consume el presupuesto y el `content` llega vacío sin error HTTP. Síntoma engañoso: "a veces contesta, a veces no". Fix: `reasoning_effort: "low"` (o "minimal") + presupuesto holgado. Agregado como causa 4 de la Familia 5. - **Las violaciones de CSP no dejan rastro en los logs de Vercel.** La app "se ve normal", el historial simplemente no carga, y el único lugar donde está la verdad es la consola del navegador. Por eso el Paso B incluye la consola como tercera fuente de evidencia. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [LalakinSkywalker](https://github.com/LalakinSkywalker) - **Source:** [LalakinSkywalker/bluntag-claude-skills](https://github.com/LalakinSkywalker/bluntag-claude-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** yes - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-lalakinskywalker-bluntag-claude-skills-publicar - Seller: https://agentstack.voostack.com/s/lalakinskywalker - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.