A coding-agent skill that clicks through your web app and texts you screenshots

Why a green check is not enough

Anyone who has used a coding agent knows the closing line: everything passes, the work is done. As dev.to reported in a post about the Kiteline app, that sentence is the least informative thing an agent can say about a change to a user interface.

The post gives the reasons. Agents can quietly relax a test until it passes, cover only the path where nothing goes wrong, or let errors disappear. The check the author trusts is the plain one: open a real browser and use the page the way a person would.

What the agent is told to do

Kiteline is an open-source desktop app for Mac, Windows and Linux. It has a companion for iPhone, iPad and Apple Watch that lets you follow coding-agent sessions, including ones run with Claude Code and Codex. One of the skills it installs gives the agent a browser-testing routine. A skill here is just a text file of instructions plus a few command-line tools.

The routine starts once the agent finishes a web feature or fix, or when you ask it to test. The agent uses Playwright, a tool that drives a real browser automatically, and saves the results as JSON, a simple structured data format.

• If your project already has Playwright, the agent uses it.
• If not, it works in a shared workspace that a setup command creates inside Kiteline's own folder, so your project stays untouched.
• If Chrome or Edge is installed, it drives that instead of downloading another browser.
• It tests at phone size, 390×844, unless the site is meant for desktop, in which case it uses 1440×900.

Tests that did not use Playwright's own test runner, such as ones written with Python Playwright, can hand over a small summary file: test names, status, duration, and one screenshot per step.

The rule against gaming the test

The most useful part may be what the skill forbids. When a check fails, the agent has to work out whether the test is mistaken or the feature is broken. If the feature is broken, it fixes the code.

It is explicitly told not to weaken the checks or strip out steps just to turn the result green. Only the report from the final run is sent, so you do not get a pile of intermediate attempts.

A report built for a small screen

A separate command turns the test results into images and posts them into the agent's current session. Each report is laid out as a web page 390 CSS pixels wide and captured at three times that resolution. On a phone, that means it fills the screen width and the text is a normal size.

The first card is an overview: whether everything passed, how many tests ran, how long it took, and the reason behind each failure. After that comes a card for each test, showing its steps in order with a screenshot for every step. Very long full-page screenshots are trimmed to the top, and a test that would make a card too tall carries on in the next one.

A report holds at most nine images, the overview plus eight cards. They are rendered three at a time. The tool first measures how tall each card will be, then captures each one separately. The computer keeps the 20 most recent full HTML reports, and the command prints where they are stored.

Skill versus prompt, and the limits

The author's argument for a skill over a prompt is convenience. You do not have to paste a reminder about browser testing into every project's instructions. The skill is switched on by default, you can turn it off in Settings, and its content can be updated online without a new version of the app.

Screenshots and reports are created on your own computer and sent straight to your phone. The rest of the app shows all agent sessions in one list, sends approval requests to the Lock Screen and Apple Watch, and does not use your API keys. The desktop side is on GitHub under the AGPL-3.0 license, and the iPhone app is on the App Store as Kiteline.

One caution: the agent still decides which flows to click through. A tidy report shows what was tested, not what was skipped, so it works best as a quick look, not as sign-off.