Specialists

Checking it actually works in a browser

A real browser walks through the feature and comes back with a verdict and screenshots.

Code
/verify the signup flow rejects weak passwords
/verify http://localhost:3000 the invite flow sends an email

What it does

Drives a real browser through the feature you described, step by step, and reports PASS or NEEDS WORK with screenshots at each point. The evidence is recorded to your project so it's still there next week.

The distinction from "it compiles" is the whole point. A feature can build, type-check, and pass unit tests while being broken in the browser.

When to use it

  • After a prototype, before you believe it.
  • Before you ship anything user-facing.
  • To reproduce a bug report — describe what the user did and watch where it diverges.
  • When a change touched something you can't easily test another way.

What "NEEDS WORK" means

It failed at a specific step and the screenshot shows the state at that step. That's usually enough to fix without reproducing it yourself. Fix, then rerun the same /verify — the wording is the test.

It needs somewhere to go

Point it at a running server. If your dev server isn't up, start it in the background first:

Code
> start the dev server in the background
> /verify the signup flow rejects weak passwords

If it doesn't work

It can't reach the app. Nothing is listening on that URL. Check the background task, and pass the URL explicitly if the port isn't the default.

It passed but the feature is broken. The description was too loose. "/verify login works" passes on a page that renders; "/verify logging in with a wrong password shows an error and doesn't redirect" doesn't.

It's slow. A browser walkthrough is minutes, not seconds. Run it in the background and carry on.

Next