1. The moment: when "the tests passed" doesn't mean "it works"
The moment arrives the day you discover an uncomfortable truth: your code being "fine" doesn't guarantee your app works. You shipped it, the tests passed green, the deploy went perfectly. And yet, a user can't log in. How? Because between your code and your user there's a whole world of things no test in your repo can see: the server, the network, a production config, a slow external API, a last-minute change.
That's the moment for Watch: when you realize you need someone actually testing the app, from the outside, like a real user — opening the browser, typing into the login, pressing the button, checking that the next screen loads. Not reviewing the code: using the app. That's called synthetic monitoring, and Watch does it for you.
2. The pain: you find out from the customer, and by then it's too late
The pain is honest and silent. It's not dramatic — it's worse: it's invisible until it costs you users. The symptoms:
- Login breaks at 3am and you find out at 9am, when the first email from a furious customer lands.
- A copy change ("Sign in" → "Log in") breaks an automated flow without anyone noticing.
- A screen starts taking 8 seconds; users don't complain, they just leave.
- An external API fails and half the app stops working, but your monitoring only checks "is the server responding" (and it responds… with a broken page).
The underlying problem: traditional monitors only check "is the server alive?". But a server can be very much alive serving a broken page. The only way to know if your app works is for someone to use it. And if that someone is always a real customer discovering the failure, you've already lost.
3. The habit: watching is CONSTANT, not a one-time check
Here's what changes your behavior: Watch is not a test you run once before launching. It's a watch round that repeats. You tell it to watch your critical flows on a schedule (every 15–30 minutes, for example) and it compares each run against the previous one. What worked in 2 seconds yesterday and takes 8 today, it catches. What passed yesterday and fails today, it catches.
The flows that are ALWAYS worth watching (the ones where, if they break, you lose money or users):
- Login — if no one can get in, your app is down for the people who are already customers.
- Sign-up — if no one signs up, you stop growing (and stop earning back the campaigns you already paid for).
- The flow that pays the bills — what the user COMES to do (create something, publish, buy).
- Checkout / payment — if it breaks, you lose revenue silently.
4. How it works, in 3 simple pieces
You don't need to understand code to get it. Watch works in three steps:
1) You describe your flows once. In a simple file (flows.json) you list the critical paths: "open /login, type the email, type the password, press Sign in, check that it reaches the dashboard." No real passwords written in there — secure variables are used instead.
2) Watch walks through them like a user. It uses agent-browser (a real browser controlled by the AI) to do exactly that: open, type, press, wait, look. It measures how long each step takes and captures screenshots.
3) It compares against the last time everything was fine. A step that used to work now fails? A flow that took 2s now takes 8s? It only warns you about what actually changed — no spam with the same alarm a hundred times.
5. How to install it: one command
Watch is a skill for Claude Code. It installs in one command and needs agent-browser as the browser engine:
/plugin marketplace add MentexDev/neuralos-watch /plugin install neuralos-watch@neuralos-watch # The browser engine (once): npm i -g agent-browser && agent-browser install
Another assistant? It also works with npx skills add MentexDev/neuralos-watch. Then you copy the example flows file, adapt it to your app, and just talk normally to your AI.
/schedule) so it runs on its own on a set interval. Honest note: it's not a magic service that runs forever on its own — it's your agent, executing your flows, on the schedule you decide.6. The ready-to-copy prompt
Here it is, end to end. Paste it into your agent (with Watch already installed), fill in the [brackets], and let the Watchman make its round:
I want you to use the neuralos-watch skill to check the health of my critical flows, in read-only and NON-destructive mode (don't delete data or make real purchases). My app's URL (point to staging/testing, not production with customer data): [https://staging.miapp.com] Critical flows to watch: [e.g. 1) that the home loads · 2) login with email+password → reaches the dashboard · 3) create a new project] Test credentials: use the environment variables [WATCH_TEST_EMAIL / WATCH_TEST_PASSWORD], never passwords written here. Follow the Watch procedure: help me define the flows.json if I don't have it, walk through each flow with agent-browser, measure timings, and hand me a report. For each problem: the exact step that failed, the screenshot, what was expected vs what you found, and the proposed fix. Also flag anything that got slow even if it didn't break. If it's the first run, establish the baseline (don't compare yet). Do NOT execute any destructive or payment step unless it's marked as safe and in a sandbox.
7. The easy path: who does what
- Walk through your flows in a real browser, step by step, like a user.
- Measure timings, capture screenshots, and detect failed network requests.
- Compare against the last good run and write you the report with the fix.
- Describe your critical flows in the example file (or ask the AI to help you do it).
- Point at a testing environment, not production with real customer data.
- Schedule the routine (/schedule) if you want automatic recurring watching.
8. The repository (free, MIT, give it a star)
Watch is open source and free. If it warned you about a break before your users did, drop it a star:
A robotic user that walks through your critical flows in a real browser with agent-browser and warns you when one breaks or slows down — with the step, the screenshot, and the fix. Read-only by default.