Ask for a browser test and get a video

“The sign-in button does nothing on Safari” is a sentence nobody can act on. A thirty-second video of the button doing nothing is a bug report. The e2e-test skill turns a list of steps into exactly that: a recorded browser run, a screenshot at every checkpoint you name, and a table that says which steps passed.

Write the steps, not the code

You start with a slash skill and then describe the flow in plain words. Everything after /e2e-test is the test specification:

/e2e-test
Target: https://app.example.com
1. Open the sign-in page and verify the email field has focus.
2. Enter a test address and click Continue.
3. Verify the code screen shows six boxes and a resend link.
4. Enter a wrong code and verify the error reads "That code did not work."

The target URL comes first, then numbered steps. Phrases such as “verify”, “expect” and “should show” mark the checkpoints that deserve a screenshot, so write them where the interesting state appears.

If the steps or the address are missing, the agent asks before it starts. It never guesses a URL and never wanders off to a different page.

What comes back

Every run produces a folder of evidence:

• A video of the whole run, with an animated cursor so a reviewer can follow the clicks at normal speed.
• Screenshots, one per checkpoint, numbered in step order and labelled with the elements on screen.
• A summary with a header line such as 4/5 steps passed, a table of step, expected result, actual result and evidence file, and notes for console errors, flakiness and environment.

A failed step does not end the run. Steps that depended on it are marked blocked, and the rest still run, so the video and the report stay complete instead of stopping at the first problem.

How a run behaves

The agent works the way a careful person would. It reads the page structure before each click, waits for an element, a URL or a piece of text rather than sleeping, and re-reads the page after anything that changes it. It types instead of pasting, so the video shows the text arriving.

Console errors count against the step. A click that another element covers is not forced; the agent dismisses the covering element first, the way a user would.

Actions are paced about a second apart so the recording is watchable, which is the one place where a fixed pause is allowed.

Set it up once per project

The skill runs its own browser tool in a separate test folder, with its own dependency list and its own artifacts. Nothing there mixes with your app’s dependencies, and the recordings and screenshots are ignored by version control. Each run also gets a named browser session, so cookies and open tabs stay with that run.

The first run needs three things:

1. The browser tool. The agent installs it into the test folder and checks the environment. If a browser or a video encoder is missing, the agent fixes what it can.
2. ffmpeg with the VP8 and H.264 encoders. On macOS, brew install ffmpeg covers it. Without it the screenshots and the summary still work; only the video is lost.
3. A running app to test. For a dev server in the same project, the agent asks whether to start it and waits until it answers before opening the browser.

Nothing else is required. The browser steps need no model and no API key.

Share a run, or keep it local

By default the evidence stays on your machine and you get the paths. If you want a link you can paste into a review, connect a Cloudflare R2 bucket once: create the bucket, make an S3 token, and fill in the four values. Each upload prints a markdown link block you can drop into a comment.

Two limits belong with those links. They expire after seven days, and the bucket deletes the objects after fourteen. A past run can be re-linked without uploading it again.

When a browser test earns its keep

A unit test is cheaper, faster and runs on every commit. Use it for logic, parsing and arithmetic.

Reach for a browser run when the failure only exists in a browser:

• layout, focus, scrolling or rendering
• a third-party widget or an embedded frame
• a redirect chain across two services
• a sign-in flow against a real provider
• a deployed page you cannot call from a test

It is also the right tool when the result has to convince another person. Reviewers can watch the cursor move and see the state that broke.

Fake data when a real model is in the way

Some flows need a model reply to move forward. For those there is a local mock model: a small server that answers every request with the same fixed text, no key and no cost. Point a local provider at it, enable the model it exposes, and map the run to it. It never calls tools, so a flow that depends on tool output still needs a real provider.

What it will not do

The skill runs the steps you give it, in order. It will not hunt for unrelated bugs, so a thin list of steps gives a thin report.

The test folder is a folder with its own toolchain, not a virtual machine or a container. It isolates dependencies and artifacts, not the whole machine.

It also refuses to type secrets. If a step needs a password, the run stops and asks you instead of putting a credential into a page.

Start a run

Open a chat in a project that has the skill, type /e2e-test, and write the flow as numbered steps with the checkpoints you care about. Ask for the video and the summary table. Start with the failing row, then watch the video up to that moment.