Cómo llevar un proyecto a producción usando un agente con CLIs y Skills

Mucho se habla últimamente de combinar CLIs con Skills para que un agente de IA pueda crear aplicaciones web de principio a fin, y que cualquier persona pueda hacer prácticamente todo por sí misma. La promesa suena bien, pero la pregunta importante es: ¿cómo se usa esto en un proyecto de verdad?

En este artículo vamos a recorrer un flujo completo y moderno de desarrollo. El agente va a construir una aplicación, va a comunicarse con su backend a través de CLI, va a desplegar el frontend con CLI, va a testear la aplicación de forma automática con CLI y, finalmente, vamos a comprobarlo en producción también de forma automática. Lo interesante es que casi todo se reduce a pedírselo al agente: tu intervención se concentra en el diseño de la aplicación y en revisar que las cosas estén bien.

El stack que vamos a usar es sencillo y replicable para cualquier proyecto tuyo:

• Frontend: Next.js + TypeScript + Tailwind + shadcn/ui
• Backend: Supabase (PostgreSQL)
• Despliegue: Railway
• Testing automático: Playwright (en desarrollo) y TestSprite (en producción)
• Agente: Cursor (aunque sirve cualquier otro)

Un punto clave antes de empezar: aunque aquí uso Cursor —principalmente por su modelo propio Composer y porque la suscripción es muy conveniente en este momento—, puedes usar el agente que prefieras. Claude Code, OpenCode o la herramienta que ya estés pagando funcionan igual, porque todas soportan Skills y CLIs, y estos CLIs se instalan en cualquiera de ellas. Si ya pagas por uno, no necesitas cambiar.

¿Por qué CLIs y Skills?

La idea de fondo es darle al agente herramientas reales con las que pueda trabajar de forma autónoma, en lugar de que tú tengas que hacer el trabajo manual de conectar bases de datos, configurar tablas o desplegar.

• Un CLI (interfaz de línea de comandos) le permite al agente ejecutar acciones concretas: crear un proyecto en la nube, correr migraciones, desplegar, testear. Lo importante es que esos comandos no los escribes tú; los ejecuta el agente.
• Un Skill es un paquete de conocimiento que le enseña al agente cómo usar ese CLI o cómo realizar una tarea específica. En la práctica, un skill suele resumir la documentación de un CLI para que el agente no tenga que andar ejecutando --help constantemente: ya tiene los comandos listados y sabe cuándo usarlos.

Los skills son un estándar abierto, así que no dependen de una herramienta específica. Esto es lo que hace que todo el flujo sea portable entre Cursor, Claude Code y el resto de agentes.

Paso 1: Empezar con el modo plan, no con la ejecución

Lo primero es crear una carpeta para el proyecto y abrirla en el editor. Antes de pedirle nada al agente, conviene cambiarlo al modo plan.

¿Por qué? Porque en modo plan el agente primero define mejor la idea, explora qué tienes en tu sistema y arma una planificación extensa antes de empezar a generar código. Esto evita gastar tokens innecesarios y estar iterando para corregir cosas que se podían haber definido desde el inicio. En Cursor, además, suele hacer preguntas extra de planificación, como cómo debe organizarse el espacio de trabajo (un usuario con sus proyectos, o espacios de trabajo para equipos).

El prompt inicial puede ser tan simple como describir la aplicación y pasarle el stack. Por ejemplo, pedir una aplicación web de gestión de proyectos al estilo Linear, especificando que use Next.js, TypeScript, Tailwind, shadcn/ui (para tener inputs, tarjetas y demás componentes ya listos) y Supabase con PostgreSQL como backend.

La aplicación tendrá una característica inteligente: un agente de IA dentro de la app que ayuda a administrar proyectos en lenguaje natural. Es como una aplicación tipo RAG, pero sencilla. Para el modelo puedes usar cualquier proveedor —Anthropic, OpenAI, Google Gemini, o un proveedor chino como MiniMax, Kimi o GLM, que están bastante populares ahora—. Incluso puedes usar el SDK de OpenAI apuntando a otro proveedor vía OpenRouter o similares.

Nota sobre costos: al integrar una IA externa necesitas una API externa, y eso se cobra por uso. Por eso usar un modelo chino suele ser beneficioso: es mucho más barato. En este recorrido uso MiniMax M3 (vía el SDK de OpenAI apuntando a su API) para demostrar que funciona con cualquier modelo inteligente, pero la parte del proveedor la puedes cambiar sin problema.

Las funcionalidades básicas que le pedimos:

• Un tablero estilo Kanban.
• Crear tareas con título, descripción y estado.
• Tareas agrupadas por proyectos.
• Un chat lateral donde el usuario describe lo que quiere en lenguaje natural; la IA procesa la petición y, mediante llamadas a herramientas (tool calls), arma tareas, las asigna y les cambia el estado, interactuando con el backend de Supabase.
• Diseño limpio, minimalista, con atajos de teclado y modo oscuro, tipo Linear.

El prompt completo

Este es el prompt que puedes usar como punto de partida (cámbialo según tu idea y tu proveedor de IA):

Crea una aplicación web de gestión de proyectos estilo Linear con un agente IA integrado.

Stack: Next.js (App Router), TypeScript, Tailwind, Supabase (Postgres + Auth), y la API de Anthropic para el agente.

Funcionalidad base:
- Tableros con vistas Kanban y lista
- Tareas con título, descripción, estado (Backlog, Todo, In Progress, Done), prioridad, asignado y fecha límite
- Proyectos que agrupan tareas
- CRUD completo vía UI

Agente IA (lo central):
- Un chat lateral donde el usuario describe lo que quiere en lenguaje natural
- El agente usa tool calling para: crear tareas desde una descripción ("arma las tareas para lanzar el landing"), asignarlas, cambiar estados, estimar tiempos y generar resúmenes de avance del proyecto
- Las herramientas (tools) deben mapear a funciones reales que escriben en Supabase

Diseño: limpio, minimalista, atajos de teclado, modo oscuro tipo Linear.

Leer la planificación, no solo ejecutarla

Cuando el agente termina de planificar, Cursor genera un detalle bastante extenso, a veces con gráficos: la estructura del frontend, los atajos, la lista, el Kanban, el chat, las acciones del agente, el uso del SDK y el backend en Supabase.

Aquí va un consejo importante: la planificación está para leerse, no solo para ejecutarse. Si sabes algo de código, léela completa. Si estás vibecodeando, al menos revisa las partes funcionales: que los conceptos clave estén, que no falte algo, que puedas añadir lo que necesites. Si todo se ve bien, puedes pedir más cosas o continuar. Recuerda que esto es un ejemplo: como los skills producen resultados consistentes, es probable que tú obtengas algo ligeramente distinto.

Paso 2: Instalar los Skills y CLIs antes de construir

Antes de darle "build", conviene instalar las herramientas para que, al momento de crear el proyecto, el agente ya cuente con todo lo que necesita.

Supabase CLI

El primer CLI es el de Supabase. Permite conectarse a la plataforma y, mediante comandos, crear proyectos, crear la base de datos, hacer migraciones y configurar todo desde consola. De nuevo: estos comandos los va a usar el agente, no tú.

En Windows se instala con Scoop. Copias los comandos, abres una terminal en Cursor y los pegas. Luego puedes confirmar con:

📖 Guía de instalación oficial: Supabase CLI – Getting Started

supabase --version

Para actualizarlo a la última versión:

scoop update supabase

El skill de Supabase

Lo siguiente es instalar el skill de Supabase, que le ayuda al agente a conocer el CLI. Al pegar el comando de instalación se lanza un asistente de bienvenida de skills donde eliges qué instalar. En este caso conviene instalar tanto PostgreSQL como Supabase, porque vamos a usar ambos.

📖 Documentación de los skills: Supabase AI Skills

El asistente también pregunta para qué agente instalarlo. Por defecto ya viene preparado para Cursor, porque Cursor soporta la carpeta .cursor. Pero si usas otra herramienta (OpenClaw o similar), puedes buscarla en la lista, marcarla con la barra espaciadora y darle Enter.

Recomendación: instala los skills a nivel de proyecto, no global. Así cada proyecto tiene sus propias herramientas en su carpeta, sin mezclar con otros proyectos de tu computadora.

Autenticarse con el CLI

Para que el agente pueda usar Supabase, primero hay que autenticar la terminal:

supabase login

Esto lanza un mensaje para abrir el navegador. Te autenticas con tu cuenta (por ejemplo, con GitHub), copias el código que te da y lo pegas en la consola. Con esto le das permiso al CLI de Supabase para conectarse.

Indicarle al agente que use el CLI en la nube

Un detalle que evita errores: en el prompt conviene ser explícito para que el agente no intente usar Supabase local. A veces el agente cree que no tiene acceso, o se produce un bug en el que ejecuta el comando y no lo encuentra. Algo así funciona bien:

"Tienes el CLI de Supabase para configurar el backend. No uses Supabase local, no descargues Supabase. Usa el CLI para crear el proyecto en la nube."

Con esto, la planificación se actualiza: el backend queda definido con supabase login, supabase projects create y los comandos correspondientes. Algo que me gusta de Cursor es que, al hacer cambios, los marca en la planificación, así que ves claramente que añadió una fase de "backend Supabase en la nube vía CLI".

Paso 3: Construir el proyecto

Ahora sí, le damos a build. El agente empieza a ejecutar las tareas (en este caso fueron siete to-dos): crea el proyecto, provisiona el backend con el CLI, genera el frontend, etc.

Tras unos minutos (en mi caso, unos 7), termina de construir todo. Lo interesante es lo que pasa sin que tú hagas nada manual:

• En el dashboard de Supabase aparece un nuevo proyecto (en mi caso, "linear-clone") que el agente creó solo.
• Si entras al Table Editor, verás las tablas ya generadas.
• Hay un diagrama entidad-relación (con un botón de autolayout para reordenarlo) donde puedes revisar que las conexiones estén bien: un proyecto se relaciona con un usuario, un usuario con un perfil, las tareas tienen project_id y user_id, etc.

Tu trabajo aquí es revisar el esquema: verificar que las relaciones sean correctas y que no falten columnas. Como es un MVP, puedes ir alterándolo. Lo importante es que toda esa conexión y configuración la hizo la IA con el CLI; tú no tuviste que conectar nada.

Configurar la API key del modelo de IA

Para que el agente interno de la app funcione, hay que añadir la API key del proveedor de IA. El agente normalmente te avisa de esto. Copias tu token (en mi caso, de MiniMax) y le dices algo como:

"Este es el token de MiniMax, añádelo aquí."

El agente lo coloca en el archivo .env.local.

⚠️ Seguridad: nunca muestres ese token a nadie. Con él pueden usar tu API y conectarse a tu Supabase. En una demo no importa tanto (y conviene eliminarlo al terminar), pero en un proyecto real consérvalo con mucho cuidado.

Ejecutar y probar la app

Le pides que ejecute el proyecto y obtienes el servidor de desarrollo. Al abrirlo:

• Te registras (usa un correo real o de pruebas, porque Supabase envía un correo de confirmación).
• En la sección de Authentication de Supabase aparece el usuario recién registrado.
• Creas un proyecto, aparece en el sidebar, y ya tienes disponible el agente de IA.

Aquí es donde empiezas a encontrar detalles a pulir. Por ejemplo, al pedirle al agente interno "crea una lista de tareas para una app de notas personales", puede que responda con texto largo pero que no renderice el Markdown o que no permita hacer scroll en respuestas largas. Le reportas esos errores:

"El chat no está renderizando Markdown, y cuando la respuesta es larga debería poder hacerse scroll dentro del chat."

El agente lo corrige (en este caso, moviendo el chat a un componente separado).

Otro detalle común: algunos modelos —como MiniMax— tienen un proceso de thinking antes de la respuesta oficial, que es como una respuesta adicional previa. Si quieres, puedes pedirle que oculte ese componente "Think" para que no aparezca en la UI.

A pesar de estos ajustes, lo central funciona: el agente crea tareas reales a partir de lenguaje natural (por ejemplo, "documentar el proyecto completo + la nube" aparece como una tarea nueva en el tablero). Obviamente la UI se puede seguir mejorando —el scroll, la carga por streaming, etc.—, pero la base está.

Paso 4: Testear en desarrollo con Playwright CLI

En vez de probar todo a mano, podemos automatizar el testing. Para eso usamos Playwright CLI, que abre un navegador y va probando cada funcionalidad.

Se instala en la terminal (en una terminal aparte de la que Cursor usa para correr el proyecto):

npm install -g playwright-cli
playwright-cli --help

Ese segundo comando solo lista los comandos disponibles; no lo vas a usar tú, lo usará el agente.

El detalle de la carpeta .claude y la portabilidad de los skills

Al instalar el skill de Playwright, puede que el instalador oficial solo cree la carpeta .claude, porque consideran a Claude como la opción principal en su CLI. Pero como los skills son estándar, la solución es simple: mueve esa carpeta dentro de tu carpeta de skills y listo. No necesitas Claude para nada.

La alternativa, si quieres un instalador universal, es usar la página skills.sh: buscas "playwright", y llegas al mismo skill, solo que ese instalador sí permite configurarlo para varios proyectos. Funciona igual que el instalador de Supabase: detecta los agentes disponibles y coloca el skill en tu carpeta skills a nivel de proyecto.

Lanzar el testing

¿Para qué hicimos todo esto? Para que ahora, en el chat, al escribir /play se autocomplete el skill (Cursor lo marca en amarillo) y puedas pedir algo simple:

"Testea todas las funcionalidades principales del proyecto."

El agente ya sabe que debe usar Playwright. Este skill funciona en modo referencia: resume los comandos del CLI para que el agente no tenga que ejecutar --help. Es, básicamente, la documentación del CLI lista para consumir.

Un extra solo para fines de demostración: puedes añadir --headed para que muestre el navegador. Por defecto Playwright trabaja de forma oculta (sin interfaz), pero en un video conviene verlo en acción:

"Usa el modo --headed para cada comando."

Esto lanza un navegador alternativo (con sus propias sesiones y cookies, separado del tuyo) que intenta registrarse, iniciar sesión y recorrer la aplicación. Puedes intervenir manualmente: iniciar sesión tú mismo y decirle "te he autenticado" (en Cursor, con la flecha para ingresar al prompt), o pasarle usuario y contraseña por el chat para que él los coloque.

Mientras trabaja, Playwright toma screenshots, revisa respuestas y a veces la consola. Al final entrega un reporte: sesión comprobada, Kanban, creación de tareas, vista en formato lista, y hasta una tarea de prueba que creó él mismo (por ejemplo, "tarea end-to-end Playwright"). Básicamente hace el proceso que harías tú, pero de forma automática.

Paso 5: Desplegar con Railway CLI

Ahora necesitamos subir el proyecto a la nube. Usamos Railway, que permite desplegar código e incluso crear bases de datos. No es la única opción —están Vercel, Render y muchas otras al mismo nivel—, pero Railway tiene la ventaja de un CLI y un agente que podemos usar al mismo estilo que Supabase.

Se instala desde la documentación de Railway, eligiendo tu sistema operativo (en Windows, con Scoop):

railway --version
railway login

railway login autentica tu sesión de terminal con tu cuenta; le das autorizar y la consola ya puede leer tu cuenta.

Si no tienes cuenta de Railway, puedes crear una gratis y usarla para desplegar proyectos.

El skill de Railway y el despliegue

Igual que con las otras herramientas, instala el skill de Railway con npx skills, a nivel de proyecto. Esto crea un skill nuevo llamado use-railway. Entonces, desde Cursor:

/use-railway → "despliega este proyecto en Railway."

Y con eso es suficiente. Dentro de tu cuenta de Railway se crea un proyecto. No hace falta desplegar el backend (ese vive en Supabase), solo el frontend (la aplicación web). Tras unos minutos obtienes una URL de producción.

Conectar producción con Supabase (otra vez vía CLI)

Para que funcione, Supabase necesita conocer la URL de producción. El agente puede avisarte que coloques esos enlaces manualmente en el dashboard, pero podemos automatizarlo:

"Actualiza tú mismo esos enlaces usando Supabase."

El agente añade las redirecciones (la nueva URL de Railway dentro de Supabase). En este punto también puede desactivar la confirmación de correo para facilitar las pruebas —conviene reactivarla una vez que todo funcione—.

Como ambos entornos comparten la misma base de datos, puedes entrar a la URL de producción con el mismo usuario que registraste antes y verás tus datos viniendo de Supabase.

Aviso realista: en producción notarás cosas a mejorar. Por ejemplo, el drag and drop puede sentirse lento porque parece refrescar todo el estado en lugar de actualizar de forma fluida. El agente interno sí funciona (al pedirle "mueve todas las tareas de To Do a In Progress", lo hace, aunque tarde un poco), pero es posible que en producción falle alguna cosa o que quieras pulir la experiencia. Para eso, hay que testear también en producción.

Paso 6: Testear en producción con TestSprite CLI

El último paso es comprobar la aplicación en producción de forma automática. Para eso uso TestSprite, una plataforma que combina un framework de testing con IA y un sistema de reportes muy útil, capaz de testear cualquier aplicación tanto en desarrollo como en producción.

En otros videos he mostrado cómo usar TestSprite vía MCP, pero ahora tienen un CLI, que permite instalar un comando para que el agente empiece a testear el proyecto en producción.

TestSprite ofrece una cuenta gratuita, sin tarjeta de crédito. Te registras (con GitHub o Google) en "Get Started Free" y entras a su panel.

Instalación y autenticación

Desde el repositorio, copias los comandos de instalación y los pegas en la terminal de Cursor:

• El primero instala el TestSprite CLI.
• El segundo ejecuta el setup, que te pide una API key.

La API key la obtienes desde tu dashboard de TestSprite: en el panel lateral hay una sección de API Keys; creas una nueva (puedes llamarla "cursor-key" o como quieras), la copias y la pegas en el editor. Con esto quedas autenticado y el agente puede usar TestSprite para manipular el navegador, entrar al sitio en producción y generar el reporte.

El skill testsprite-verify

Igual que con los otros agentes, TestSprite crea su propio skill, llamado testsprite-verify. Recomiendo copiarlo a tu carpeta de skills (clic derecho → copiar → pegar). Aunque Cursor puede leer la carpeta .claude, si usas otra herramienta (Antigravity, Kiro, VS Code o cualquier otra), tenerlo en tu carpeta genérica de skills garantiza la portabilidad.

Con el skill listo, puedes pedir:

"Ayúdame a testear el proyecto usando TestSprite" — o cargar el skill con /testsprite-verify.

Si revisas el skill, verás que resume cómo ejecuta un loop de testing: entrar a la URL de producción, navegar, crear el PRD y dar el reporte. (Casi todo el mundo está promoviendo el uso de loops; en este caso no es el loop típico de agentes, sino el proceso de verificación.) Esos comandos son para el agente, no para ti; lo que importa es la parte donde empieza a ejecutarse.

Los reportes en producción

Tras esperar un poco, obtienes el resultado: la URL de producción revisada y los tests que pasaron. Y aquí está lo potente de TestSprite: en su dashboard ves un resumen visual de todo lo testeado, e incluso graba un video paso a paso de cómo llena los campos.

En el recorrido testeó, entre otras cosas:

• El registro (creando cuenta y entrando al panel).
• La creación de un proyecto desde una cuenta nueva.
• Que el landing cargue.

Lo interesante es que el propio agente detecta lo que falta. Me dijo "cobertura pendiente: no está testeado el panel de IA con MiniMax ni el command palette". Al pedirle que añada esos tests, comprobó características faltantes: el command palette, editar una tarea, editar el título de una tarea, etc. En el dashboard ves cómo se van agregando tests y cuáles pasan.

También puedes regenerar un test (botón regenerate) para que lo vuelva a probar, o intervenir en los pasos: por ejemplo, cambiar el correo o la contraseña en un paso concreto y darle Save and Run. Si un test falla, te dice exactamente en qué (por ejemplo, "estás intentando registrar un usuario que ya existe", o una contraseña incorrecta), y puedes ajustarlo y reintentar.

La gran ventaja: tienes un panel donde se testea la aplicación en producción, mientras los otros skills lo hacen en desarrollo. Dos capas de testing automático trabajando para ti.

Conclusión

Crear una aplicación y lanzarla a producción es relativamente sencillo cuando ya tienes los skills y las herramientas típicas instaladas. En este recorrido:

1. Creamos una planificación en modo plan.
2. Se construyó el proyecto completo.
3. Se testeó en desarrollo con un skill (Playwright).
4. Se desplegó con un skill (Railway).
5. Se testeó en producción usando skills + CLIs (TestSprite).

A partir de aquí, todo es iterar sobre tus ideas: redesplegar, hacer más cambios, mejorar la UI. Construimos una aplicación en poco tiempo, pero de aquí en adelante el límite es lo que tú quieras crear.

El gran cambio de enfoque es este: en lugar de hacer el trabajo manual de conectar bases de datos, configurar tablas, desplegar y testear, le das al agente herramientas reales (CLIs) y conocimiento (Skills) para que lo haga por sí mismo. Y como los skills son un estándar abierto, todo este flujo es portable entre Cursor, Claude Code, OpenCode y cualquier otro agente que prefieras.

Si quieres conocer más, te dejo mis enlaces sociales y mi web fazt.dev, donde puedes reservar asesorías personalizadas de cualquier tema. Y no olvides dejar un comentario con tu duda o sugerencia para el siguiente artículo.