1. El momento: cuando "pasó los tests" no significa "funciona"
El momento llega el día que descubres una verdad incómoda: que tu código esté "bien" no garantiza que tu app funcione. Lo lanzaste, los tests pasaron en verde, el deploy salió perfecto. Y aun así, un usuario no puede iniciar sesión. ¿Cómo? Porque entre tu código y tu usuario hay un mundo de cosas que ningún test de tu repo ve: el servidor, la red, una configuración de producción, una API externa lenta, un cambio de último minuto.
Ese es el momento de Watch: cuando entiendes que necesitas a alguien probando la app de verdad, desde fuera, como un usuario real — abriendo el navegador, escribiendo en el login, pulsando el botón, comprobando que la pantalla siguiente carga. No revisando el código: usando la app. Eso se llama monitoreo sintético, y Watch lo hace por ti.
2. El dolor: te enteras por el cliente, y eso ya es tarde
El dolor es honesto y silencioso. No es dramático — es peor: es invisible hasta que te cuesta usuarios. Los síntomas:
- El login se rompe a las 3am y te enteras a las 9am, cuando llega el primer correo de un cliente furioso.
- Un cambio de copy ("Iniciar sesión" → "Entrar") rompe un flujo automatizado sin que nadie lo note.
- Una pantalla empieza a tardar 8 segundos; los usuarios no se quejan, simplemente se van.
- Una API externa falla y media app deja de funcionar, pero tu monitoreo solo mira "si el servidor responde" (y responde… con una página rota).
El problema de fondo: los monitores tradicionales solo comprueban "¿el servidor está vivo?". Pero un servidor puede estar vivísimo sirviendo una página rota. La única forma de saber si tu app funciona es que alguien la use. Y si ese alguien es siempre un cliente real descubriendo el fallo, ya perdiste.
3. El hábito: vigilar es CONSTANTE, no una revisión de una vez
Aquí está lo que cambia tu comportamiento: Watch no es una prueba que corres una vez antes de lanzar. Es una ronda de vigilancia que se repite. Le dices que vigile tus flujos críticos cada cierto tiempo (cada 15-30 minutos, por ejemplo) y compara cada corrida contra la anterior. Lo que ayer funcionaba en 2 segundos y hoy tarda 8, lo detecta. Lo que ayer pasaba y hoy falla, lo detecta.
Los flujos que SIEMPRE vale la pena vigilar (los que, si se rompen, pierdes dinero o usuarios):
- Login — si nadie entra, tu app está caída para los que ya son clientes.
- Registro — si nadie se registra, dejas de crecer (y de cobrar campañas que ya pagaste).
- El flujo que te da de comer — lo que el usuario VIENE a hacer (crear algo, publicar, comprar).
- Checkout / pago — si se rompe, pierdes ingresos de forma silenciosa.
4. Cómo funciona, en 3 piezas simples
No hay que entender de código para captarlo. Watch trabaja en tres pasos:
1) Tú describes tus flujos una vez. En un archivo sencillo (flows.json) listas los caminos críticos: "abre /login, escribe el email, escribe la contraseña, pulsa Iniciar sesión, comprueba que llega al panel". Sin contraseñas reales escritas ahí — se usan variables seguras.
2) Watch los recorre como un usuario. Usa agent-browser (un navegador real controlado por la IA) para hacer exactamente eso: abre, escribe, pulsa, espera, mira. Mide cuánto tarda cada paso y captura pantallas.
3) Compara con la última vez que todo iba bien. ¿Un paso que antes funcionaba ahora falla? ¿Un flujo que tardaba 2s ahora tarda 8s? Solo te avisa de lo que cambió de verdad — nada de spam con la misma alarma cien veces.
5. Cómo se instala: un comando
Watch es una skill para Claude Code. Se instala en un comando y necesita agent-browser como motor del navegador:
/plugin marketplace add MentexDev/neuralos-watch /plugin install neuralos-watch@neuralos-watch # El motor del navegador (una vez): npm i -g agent-browser && agent-browser install
¿Otro asistente? También funciona con npx skills add MentexDev/neuralos-watch. Luego copias el archivo de ejemplo de flujos, lo adaptas a tu app, y le hablas normal a tu IA.
/schedule) para que corra solo cada cierto tiempo. Honestidad: no es un servicio mágico que corre solo para siempre — es tu agente, ejecutando tus flujos, en el horario que tú decidas.6. El prompt listo para copiar
Aquí lo tienes de extremo a extremo. Pégalo en tu agente (con Watch ya instalado), rellena los [corchetes] y deja que la Vigía haga su ronda:
Quiero que uses la skill neuralos-watch para revisar la salud de mis flujos críticos, en modo read-only y NO destructivo (no borres datos ni hagas compras reales). URL de mi app (apunta a staging/pruebas, no a producción con datos de clientes): [https://staging.miapp.com] Flujos críticos a vigilar: [ej. 1) que el home cargue · 2) login con email+contraseña → llega al panel · 3) crear un proyecto nuevo] Credenciales de prueba: usa las variables de entorno [WATCH_TEST_EMAIL / WATCH_TEST_PASSWORD], nunca contraseñas escritas aquí. Sigue el procedimiento de Watch: ayúdame a definir el flows.json si no lo tengo, recorre cada flujo con agent-browser, mide tiempos, y entrégame un reporte. Por cada problema: el paso exacto que falló, el screenshot, qué se esperaba vs qué encontraste, y el fix propuesto. Marca también lo que se puso lento aunque no se haya roto. Si es la primera corrida, establece la baseline (no compares todavía). NO ejecutes ningún paso destructivo o de pago salvo que esté marcado como seguro y en sandbox.
7. El camino fácil: quién hace qué
- Recorrer tus flujos en un navegador real, paso a paso, como un usuario.
- Medir tiempos, capturar pantallas y detectar peticiones de red fallidas.
- Comparar contra la última corrida buena y escribirte el reporte con el fix.
- Describir tus flujos críticos en el archivo de ejemplo (o pedirle a la IA que te ayude a hacerlo).
- Apuntar a un entorno de pruebas, no a producción con datos reales de clientes.
- Programar la rutina (/schedule) si quieres vigilancia automática recurrente.
8. El repositorio (gratis, MIT, dale una estrella)
Watch es de código abierto y gratis. Si te avisó de una rotura antes que tus usuarios, déjale una estrella:
Un usuario robótico que recorre tus flujos críticos en un navegador real con agent-browser y te avisa cuándo uno se rompe o se pone lento — con el paso, el screenshot y el fix. Read-only por defecto.