The AI Playwright test generator where the prompt is 18 lines and the output is Markdown you own

Three JPEG screenshots and up to 8000 characters of accessibility-snapshot text, plus one prompt. The implementation is at /Users/matthewdi/assrt-mcp/src/mcp/server.ts lines 793-834. The assrt_plan tool launches a local Chromium via Playwright MCP, navigates to your URL, calls screenshot() and snapshot(), scrolls by 800 pixels, captures again, scrolls by 800 pixels, captures a third time. It then slices the concatenated accessibility text to 8000 chars, wraps the three screenshots as base64 image parts, and hands everything to claude-haiku-4-5-20251001 with max_tokens 4096. The model returns a plan string containing 5 to 8 #Case blocks, which is the test file the runner will later execute. Nothing about the payload is hidden; you can run the flow in your terminal and inspect every byte.

Yes, and you do not have to scrape it from a request log. It lives in the repo at /Users/matthewdi/assrt-mcp/src/mcp/server.ts lines 219-236 as a constant named PLAN_SYSTEM_PROMPT. The prompt is 18 lines long and covers four things: (1) what the browser agent can and cannot do, (2) the exact output format (#Case N: name followed by steps), (3) six CRITICAL Rules (self-contained cases, specific selectors, observable verifications, short 3-5 action cases, no features behind auth unless visible, 5-8 cases max), and (4) the constraint that it is generating for an AI agent that cannot inspect CSS or run arbitrary JavaScript. Closed-source generators like BrowserStack Playwright AI, ZeroStep, and Playwright's own Generator agent do not publish this. If you want to change behavior, you fork the file and ship. No waiting on a vendor.

Playwright's Generator agent writes TypeScript spec files that contain locator strings and call expect(). That is lovely if you already have a Playwright project and want AI-written .spec.ts code committed to it. Assrt writes something different: plain Markdown with intent ('Click the Sign up button', 'Assert the heading says Dashboard'), stored at /tmp/assrt/scenario.md. When the Assrt runner later executes those cases, it re-discovers every element from the live accessibility tree per step, so the tests never contain locator strings that can rot. Both approaches use @playwright/mcp under the hood; the difference is the artifact they hand you. If you want an AI to write you TypeScript that you will later maintain, use Playwright Generator. If you want an AI to write you an intent description that it will execute forever without ever binding to a selector, use Assrt.

No. The generator output is literally a string containing #Case blocks in Markdown. You can paste it into a gist, check it into Git, render it on GitHub, grep it, diff it, run it through a linter, or copy half of it into another project. The scenario layout is defined at /Users/matthewdi/assrt-mcp/src/core/scenario-files.ts: scenario.md is the plan, scenario.json is metadata (ID and name), results/latest.json is the last run. Closed AI Playwright generators like Testim, Mabl, and Momentic store the generated test cases in their own backend and render them in their own dashboard; moving off their platform means re-authoring everything from scratch. Assrt's format is a flat file on your disk, so migration cost in either direction is the text of the file.

Three screenshots with scroll gives the model a fair shot at seeing the hero, the mid-page content, and below-the-fold features without blowing past context limits on a long landing page. A single full-page screenshot gets compressed and text becomes unreadable for the model. Feeding the raw DOM drowns the model in divs and inline styles that do not help it reason about user-visible flows. The 8000-char accessibility snapshot fits under Haiku's token budget, leaves room for the screenshots, and keeps the roles, labels, and text content that matter for generating test cases. The three-screenshot choice is a deliberate trade between coverage and token cost, and the constant 800 (pixels per scroll) is right there at server.ts:797 and 802 if you want to tune it.

claude-haiku-4-5-20251001, called with max_tokens 4096 (server.ts:830-831). Haiku is the right default: generating a test plan from a URL is a bounded task with a clear output shape, and Haiku is fast and cheap for it. If you want a bigger model for richer test ideas, the assrt_plan MCP tool accepts a model parameter, and the whole pipeline honors the ANTHROPIC_BASE_URL environment variable, so you can point at a local proxy, a hosted clone, or an air-gapped endpoint. For teams with strict data policies, this matters because the generator payload (your URL, your screenshots, your accessibility tree) only ever leaves your machine if you let it.

Most flakiness in AI-generated Playwright tests comes from two sources: brittle locator strings that the model guessed and hardcoded sleeps that do not match real page timing. Assrt sidesteps both. The generator writes intent in Markdown, not locator strings, so there is nothing for a locator change to break. The runner uses a wait_for_stable primitive backed by a MutationObserver (defined at agent.ts:872-925 in the assrt repo), which waits until 2 consecutive seconds pass with zero DOM mutations or 30 seconds elapse, so fast pages return fast and streaming pages wait as long as they actually need. Between those two decisions, the kind of flakiness you see on Reddit threads for AI codegen tools mostly does not happen. What does happen: a test can fail because the app genuinely changed in a way your intent no longer covers, in which case you run assrt_diagnose and get a corrected #Case to paste back in.

Yes, and this is the workflow most people settle into. The generator's job is to do the first 80 percent: recognize the visible flows on a URL and draft self-contained cases. Then you open /tmp/assrt/scenario.md in your editor, tweak the wording, delete the ones you do not care about, add a case the generator missed (a pattern it could not see because it is behind auth), save. The runner auto-syncs edits to cloud storage via a file watcher, but the authoritative copy is still the file on your disk. You can also check scenario.md into your repo next to your Playwright project as your living test spec; the whole point of the Markdown format is that it survives tooling changes.

Two paths. Through an MCP-capable client like Claude Code: connect the assrt-mcp server (one line in your MCP config), then ask 'Use assrt_plan on http://localhost:3000'. The tool launches a local browser, takes the three screenshots, sends them to Haiku, and writes the result. Or from the CLI: npx assrt-mcp is the entry point (see /Users/matthewdi/assrt-mcp/src/cli.ts), and you can call it with --plan to generate, --run to execute, or combined. Both paths require an Anthropic credential; the getCredential helper (server.ts:777) supports both API keys and OAuth tokens, so you can use a Claude Pro subscription or a raw key depending on your setup.

The accessibility snapshot. Everything the model writes about selectors, buttons, and labels has to trace back to nodes that actually appeared in the snapshot text it was given, because the runner will later try to find those nodes for real. A hallucinated 'Click the Checkout button' on a page with no Checkout button fails the moment the test runs, and assrt_diagnose will call it out. In practice, the stricter constraint is the PLAN_SYSTEM_PROMPT rule that each case must be SELF-CONTAINED and VERIFY OBSERVABLE THINGS (visible text, page titles, URLs, element presence). That rule alone kills the two biggest hallucination patterns for AI test generation: tests that assume invisible state and tests that assert on CSS. Everything left is grounded in what the model literally saw in the three snapshots.