Dev.to AI 🤖 Ai 👁 0 📖 3 min read

Letting coding agents verify their own UI changes with Playwright and send a phone-friendly report

"Done, all tests pass" is the least useful sentence a coding agent can write about a UI change. Tests get loosened, only the happy path gets covered, errors get swallowed. The reliable check is still the boring one: open

"Done, all tests pass" is the least useful sentence a coding agent can write about a UI change. Tests get loosened, only the happy path gets covered, errors get swallowed. The reliable check is still the boring one: open a real browser and click through it like a user would.

Kiteline is an open-source desktop app (Mac, Windows, Linux) with an iPhone, iPad and Apple Watch companion that follows coding-agent sessions such as Claude Code and Codex. One of the skills it installs into those agents does exactly that check, and sends the result to the phone as a report you can read in a few seconds. Here is how it is put together.

The flow the agent follows

The skill is a plain instruction file plus a few CLI commands, installed for Claude Code and for other agents (Codex, OpenCode, DeepSeek Harness) on the local machine and on machines reached through Remote-SSH. After finishing a web feature or fix, or when the user says "test it", the agent:

  1. Uses the project's own Playwright if there is one, writing results as JSON.
  2. Otherwise uses a shared workspace that e2e-setup creates under Kiteline's own directory. Nothing is added to the user's project. If Chrome or Edge is already installed it is used as the Playwright channel instead of downloading a browser.
  3. Runs at phone size by default (390×844), or 1440×900 for desktop sites.
  4. Hands the results to report, which turns them into images and posts them into the current session.

Non-Playwright-Test runs (for example Python Playwright) can pass a small manifest instead: tests, status, duration, and one screenshot per step.

The skill also tells the agent what not to do when something fails: decide whether the test or the feature is wrong, fix the code if it is the feature, and never loosen assertions or delete steps to make it pass. Only the final run's report is sent.

Rendering for a phone

The report is laid out as HTML at a 390 CSS-pixel width and captured at 3x, so on the phone it fills the screen width with normal-sized text:

  • An overview card: passed or not, number of tests, duration, and the reason for each failure.
  • One card per test with its steps in order and a screenshot per step. Full-page screenshots are clipped to their top part; a test that would get too tall continues on the next card.
  • At most nine images per report (overview plus eight cards), rendered three at a time in parallel.

The card heights are measured by dumping the rendered DOM first, then each card is captured separately. The last 20 full HTML reports are kept on the computer, and the command prints the path.

Why a skill, not a prompt

Users do not have to add "remember to test in a browser" to every project prompt. The skill is on by default, can be switched off in Settings, and its content updates online without a new app release. Screenshots and reports are produced on the user's own computer and sent straight to their phone.

The rest of Kiteline

Kiteline puts every agent session from every computer in one list, sends approvals to the Lock Screen and Apple Watch, separates "things only you can do" into to-dos, sends credentials as copyable key-info cards, and has a pixel-art "world mode" where each session is a character at a desk. It does not use your API keys or change agent settings. The desktop side is on GitHub under AGPL-3.0; the iPhone app is on the App Store as "Kiteline".

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.