Controla tu aplicación web usando CLIs y Skills

Una de las formas más fáciles de comunicar tu sistema con una IA es combinando un CLI con un skill. Decirlo es sencillo, pero verlo en la práctica es otra cosa. Por eso en este artículo vamos a construir un sistema completo desde cero: una aplicación web simple, un CLI que la manipule y un skill para que cualquier agente —Claude Code, Codex, Cursor y muchos más— pueda controlar tu sistema a través de comandos.

Si has escuchado que muchas plataformas están ofreciendo "CLI + skills" y no terminas de entender por qué este paradigma se está usando tanto, aquí lo vas a ver de forma práctica. Y si nunca has desarrollado algo así, es un ejercicio bastante fácil de lograr.

La idea general

Para no complicarnos, vamos a crear un CRUD: una aplicación que permite crear, leer, actualizar y eliminar datos. Es el ejemplo clásico de toda la vida, pero con un giro interesante: no vamos a interactuar con la interfaz. Cualquiera puede hacer eso. Lo que haremos es manipular el sistema a través de un programa intermedio —el CLI— y, más importante aún, no lo vamos a usar nosotros directamente: la idea es que un agente de IA use ese CLI para manipular nuestro sistema y también para consultar datos desde allí.

Con esta idea tan básica podemos lograr algo muy similar a lo que hace un MCP.

Ahora, un CLI son comandos, y tu agente no los conoce de entrada. Ahí entran dos piezas:

1. El comando --help, típico en toda herramienta de línea de comandos: al ejecutarlo, el CLI te dice qué otros comandos hay disponibles. Es la forma en que un agente puede "descubrir" tu herramienta.
2. El skill, un archivo markdown que le da al agente un resumen de los comandos disponibles sin que tenga que ejecutar nada. Apenas lo invocas, el agente ya conoce tu CLI.

El stack

Algo interesante de esta arquitectura es que el frontend, el backend y el CLI pueden estar desarrollados cada uno en un lenguaje distinto. Para dejar clara la distinción entre las partes, vamos a usar:

• Frontend: React con Vite y TypeScript
• Backend: Python con FastAPI y PostgreSQL como base de datos
• CLI: Node.js con JavaScript (aunque podría ser Go, Rust, Python, Bash o cualquier lenguaje, porque todos permiten crear aplicaciones de consola)

El skill, por su parte, es un markdown y es un estándar, así que no importa qué lenguaje escojas: al final va a funcionar con cualquier agente.

Para generar el proyecto voy a usar Cursor, pero no es obligatorio: puedes usar Claude Code, Codex, OpenCode o el agente que prefieras. El resultado es el mismo.

Este stack es simple, pero hay muchos que creen que para que un agente manipule tu programa necesitas sí o sí un MCP o un RAG. Aquí vamos a lograrlo con algo mucho más sencillo.

Creando la aplicación web

Empezamos por el frontend más la API, porque justamente necesitamos la API para comunicar el sistema con lo demás. Creamos un proyecto llamado task-cli-ai y le damos un prompt de este estilo:

Crea una aplicación de administración de proyectos donde cada proyecto puede tener tareas y las tareas tienen una vista Kanban. El backend es Python con PostgreSQL y el frontend React con Vite y TypeScript.

Si no conoces la vista Kanban: son esas aplicaciones con columnas y tarjetas que puedes mover de un lado a otro, donde cada movimiento representa un cambio de estado (pendiente, en progreso, hecho). Es una buena forma de administrar tareas.

Un consejo: usa el modo plan antes de ejecutar. La mayoría de agentes lo tienen (Claude Code, Codex, OpenCode, Cursor) y te lanza algunas preguntas antes de escribir código. En mi caso me preguntó por autenticación (le dije que no, para mantener el ejemplo simple) y cómo quería ejecutar PostgreSQL. Yo escogí Docker, pero si no lo conoces puedes instalar Postgres localmente o usar SQLite; yo usé Postgres porque es lo que voy a desplegar después.

Después de unos 10 minutos tenemos el proyecto generado y corriendo. Le pedí también la vista Kanban a partir de las tareas, y con eso ya podemos crear tareas y arrastrarlas entre columnas, con los cambios de estado persistiendo en la base de datos.

Algo que vale la pena notar: al usar FastAPI, el backend genera automáticamente la documentación de sus rutas. Esos son los endpoints del sistema: el CRUD de proyectos, las rutas para obtener las tareas de un proyecto, crearlas, actualizarlas o eliminarlas. Dos entidades (proyecto y tarea) y nada más. Esa API es justo lo que va a consumir nuestro CLI.

Creando el CLI

Ahora sí, le pedimos al agente:

Crea un CLI que interactúe con la API, desarrollado en Node con JavaScript.

De nuevo, aquí no uso TypeScript a propósito, solo para que se vea la distinción de lenguajes entre las partes. En pocos minutos obtenemos una carpeta cli con una herramienta instalable. Ahora el backend está siendo consumido por dos clientes: el frontend web y la herramienta de consola.

El agente le puso de nombre task, así que desde la terminal podemos probar el comando clásico:

task --help

Y nos responde con todos los comandos disponibles. Por ejemplo:

task projects list      # lista los proyectos
task projects get 3     # obtiene un proyecto por ID
task tasks list 3       # lista las tareas del proyecto 3

Si comparamos con la aplicación web, vemos exactamente los mismos datos: los mismos proyectos, las mismas tareas. Estamos manipulando el mismo backend desde otro cliente.

Pero recuerda: estos comandos no son para nosotros, son para que el agente pueda leerlos.

Un agente controlando tu sistema

Abrimos una terminal aparte y lanzamos Codex (o el agente que quieras). Le damos una instrucción muy simple:

Usando el CLI task que está instalado en este computador, crea 10 proyectos nuevos con tareas de ejemplo.

Lo que hace el agente es fascinante de ver: llama --help varias veces para entender qué comandos puede ejecutar, y una vez que los descubre, empieza a lanzarlos. En unos segundos me confirma que generó los proyectos con IDs del 5 al 14, y al refrescar la aplicación web ahí están todos, cada uno con su tarea de ejemplo.

Lo mismo funciona para eliminar ("elimina los proyectos del 7 al 10") o para mover estados:

En el proyecto de ejemplo número seis, mueve todas las tareas al estado hecho.

El agente encuentra el comando move, lo ejecuta, y al refrescar la vista Kanban las tarjetas están en la columna correcta.

Bonus: actualización en tiempo real con Server-Sent Events

Como tenía que refrescar la página para ver los cambios, le pedí al agente algo más:

En el frontend y en el backend implementa Server-Sent Events para que se actualicen tanto los proyectos como las tareas.

Los SSE son como la mitad de un WebSocket: cuando otro programa actualiza el sistema, el backend notifica al frontend y este se actualiza solo. Con esto implementado, le digo al agente "crea dos proyectos nuevos" y los veo aparecer en pantalla inmediatamente, sin refrescar. Es casi la misma experiencia que usar un MCP, porque el agente está interactuando directamente con mi sistema.

Incluso podemos usarlo como puente de inteligencia: le dije "crea un proyecto llamado desarrollo de e-commerce" y luego "crea todas las tareas de este proyecto", y el agente generó un backlog completo desde definición hasta despliegue. Mi aplicación no tiene IA integrada, pero el CLI le da al agente un puente para trabajar dentro de ella.

Añadiendo el skill

Hasta ahora el agente tuvo que descubrir los comandos con --help. Podemos ahorrarle ese paso con un skill.

Un skill es básicamente un markdown —casi como un README— que resume los comandos del CLI. Se guarda en una carpeta de skills con un archivo SKILL.md adentro, típicamente nombrado en snake_case. El contenido es algo así: el nombre y descripción de la herramienta ("puedes operar con task, un CLI de Node que ejecuta consultas contra proyectos y tareas y tiene vista Kanban") y luego los comandos con ejemplos de uso: cómo consultar proyectos, cómo consultar tareas, cómo crear, mover y eliminar.

No necesita estar extremadamente detallado. La gracia es que en lugar de que el agente esté ejecutando --help a ciegas, apenas invocas el skill ya tiene todo el resumen del CLI cargado en su contexto.

Le pedimos al agente:

Crea un skill en este mismo proyecto para el CLI que acabamos de crear.

Es una tarea que hace muy rápido. Ahora, un detalle importante: cada herramienta lee los skills desde su propia carpeta. Codex, OpenCode y otros agentes siguen el estándar de la carpeta .agents, que es leída por prácticamente todos. Pero herramientas como Claude Code tienen su carpeta propia (.claude) donde tienes que repetir exactamente el mismo skill. Si vas a crear uno, soporta la mayor cantidad de agentes posible, o al menos los que uses. Y ni siquiera tienes que copiarlo manualmente:

Ahora copia este skill en .codex, .claude y .agents.

Con eso instalado, abro Claude Code, invoco el skill escribiendo /task-cli y le digo:

Crea dos proyectos, uno llamado Kanban App y otro llamado REST API CRUD.

No tuve que decirle qué comando usar ni explicarle de qué se trata: el skill ya le da el contexto. Los proyectos aparecen en la aplicación y me devuelve hasta los IDs. Esta es, de hecho, la forma en la que funcionan agentes como Hermes u OpenClaw, así que todo esto también aplica allí.

Cómo lo hacen las plataformas reales

Este paradigma no es teórico: es exactamente lo que están ofreciendo muchas plataformas de nube y servicios externos.

Railway, que uso bastante para mis proyectos, ofrece su propio CLI y su propio skill. El CLI sirve para desplegar tu proyecto en su nube desde comandos, y el skill para que tu agente sepa qué comandos existen. Se instala desde npm (disponible para Windows, Linux y Mac), luego ejecutas railway login para autorizar tu cuenta —el flujo típico de estas plataformas: te abren el navegador y vinculan tu sesión web con la consola— y finalmente instalas el skill con npx skills, un instalador que te deja elegir entre la carpeta .agents (accesible para todos los agentes) o la carpeta dedicada de cada herramienta.

Con todo listo, abrí el proyecto con Claude Code, invoqué el skill de Railway y le dije algo tan simple como:

Despliega todo el proyecto.

Antes esto era entrar a la plataforma, hacer clics, configurar servicios. Ahora es la misma idea que aplicamos con nuestro propio proyecto: un CLI que viene de parte de Railway para que un agente manipule su plataforma. Después de unos 20 minutos, el backend y el frontend quedaron desplegados con sus dominios, y la base de datos PostgreSQL corriendo como parte del stack. Creé un proyecto de prueba desde el frontend en producción y ahí estaba el registro en las tablas. El CLI no se despliega porque es una herramienta cliente que corre en el computador de cada usuario.

TestSprite es otro ejemplo que uso después de desplegar. También tiene su CLI y su skill, y sirve para comprobar que el proyecto funciona bien ya en la nube. Te registras gratis, instalas su comando globalmente con npm, ejecutas el setup con una API key de tu panel, y con eso se instalan tanto el CLI como los skills que vienen incluidos (otra forma de distribución: hay quienes empaquetan el skill junto con su herramienta de consola).

Desde una instancia de Claude Code le dije "testea este proyecto usando TestSprite" y la herramienta empezó a generar y ejecutar tests contra el backend y el frontend en producción: comprobó el CRUD completo, la actualización por Server-Sent Events, la interfaz Kanban. Además graba cada test para que puedas revisarlo, y puedes editarlos y relanzarlos. En mi caso, la API pasó todos los tests, pero en el frontend falló uno: al arrastrar una tarea en progreso, el nuevo estado no persistía correctamente. La grabación me mostró exactamente en qué parte falla. Y ese es el uso real de esto: cuando algo falla, tienes evidencia concreta de qué revisar, sin haber implementado el testing tú mismo desde cero.

¿Cómo se distribuye un CLI?

A diferencia del frontend o el backend, el CLI no se "despliega": quien lo va a usar tiene que descargarlo y ejecutarlo en su máquina. Para eso existe npm (o pnpm), que es la forma típica: subes tu herramienta de consola al registro y otros la instalan con un comando, igual que hicimos con Railway y TestSprite. También hay formas de alojarlo gratuitamente en GitHub y otras opciones para distribuir el CLI junto con sus skills, pero eso da para un artículo aparte.

Conclusiones

Crear un CLI más skills es una de las opciones más comunes que están ofreciendo las plataformas hoy, y si estás creando tus propios proyectos web, considera desarrollar uno: es una opción muy sencilla que le permite a múltiples agentes interactuar con tu sistema.

Algunas consideraciones finales:

• Autenticación: en este ejemplo no la implementé, pero es un paso importante y se implementa de forma muy similar a como se hace en una API.
• Mantenimiento: un CLI es, al final, otra aplicación cliente adicional que tienes que mantener. Tenlo en cuenta si es para uso personal versus para un cliente, porque a veces tus clientes no lo van a entender del todo.
• Audiencia: el CLI + skill está enfocado en usuarios técnicos. Si quieres darle acceso a un usuario normal, un MCP es una forma más amigable. Y la otra opción es un RAG, según lo que necesites.

Con una idea tan simple —una API, un CLI que la consume y un markdown que lo documenta— tienes un puente entre cualquier agente de IA y tu sistema, sin necesidad de infraestructura adicional.