A Playwright test generator that reads your user flows off the live page, no recording required

It means the generator looks at the page itself instead of looking at you. When you run `npx @m13v/assrt discover https://your-app.com`, the assrt_plan tool launches a local Chromium via @playwright/mcp, navigates to that URL, takes a screenshot and accessibility snapshot, scrolls 800 pixels, captures again, scrolls another 800 pixels, captures a third time. Those three screenshots plus 8000 characters of concatenated accessibility text get handed to claude-haiku-4-5-20251001 with one specific instruction: write 5-8 short cases focused on the most important user flows visible on the page. Implementation is at /Users/matthewdi/assrt-mcp/src/mcp/server.ts lines 793-834. The model sees the same things a human would scrolling your homepage, so the cases it produces are the flows a real visitor would attempt: sign up, click pricing, check the demo, read the docs.

Because without that phrase the model writes assertions, not flows. Early drafts of the prompt produced cases like 'verify the H1 says "Welcome"' or 'check that the email input has the correct placeholder.' Useful as a smoke check, useless as a behaviour test. Rule #6 in PLAN_SYSTEM_PROMPT at server.ts:236 anchors the model on flows: a flow is a sequence with intent, not a single attribute check. The other five rules constrain the shape (self-contained, specific selectors named in English, observable verifications, 3-5 actions max, skip features behind auth unless visible). The combination is what makes the output runnable without further editing 90% of the time.

Three captures is a deliberate trade between coverage and token cost. A single full-page screenshot gets so compressed by the model's vision encoder that text becomes unreadable. Feeding the raw DOM drowns the model in inline styles and divs that do not help it reason about flows. Three captures at scroll 0, 800, 1600 give the model a fair shot at the hero, the mid-page content, and the first set of features below the fold without exceeding Haiku's context budget. For pages longer than 2400 pixels, the discoverable flows come from above-the-fold actions anyway: nav links, hero CTAs, pricing tiles, sign-up forms. If a flow only starts when you scroll past the third screenshot, it will not be in the generated plan, and that is a known limitation. The constants are at server.ts:797 and 802. They are tunable in the source, not in a vendor dashboard.

Playwright codegen is a record-then-tweak tool. You drive the browser, it watches your clicks and types, and it emits a .spec.ts file with locator strings and expect calls. The flow is yours, the recording is yours, the resulting code is yours to maintain. Assrt's assrt_plan tool inverts every part of that. Nobody drives the browser, the tool drives itself by scrolling and snapshotting. The flow is inferred from the page, not from a human session. The output is intent-based Markdown saved to /tmp/assrt/scenario.md, not a TypeScript file with locators. And the runner re-discovers every element from the live accessibility tree at execution time, so the test does not bind to a selector that can rot. Both approaches sit on top of @playwright/mcp under the hood; they hand you genuinely different artifacts.

It is a plain Markdown file at /tmp/assrt/scenario.md, layout defined in /Users/matthewdi/assrt-mcp/src/core/scenario-files.ts. The shape is `#Case 1: short action-oriented name` followed by 3-5 numbered steps. Steps are written in English: 'Navigate to /signup', 'Type test@example.com into the email field', 'Click the Sign up button', 'Assert the heading says Dashboard'. There are no locator strings in the file. There is no proprietary YAML schema, no vendor JSON, no DSL. You can grep the file, diff the file, commit the file to your repo, render it on GitHub, paste half of it into another project, or hand-edit it before re-running. When you call assrt_test against the same URL, the runner reads scenario.md and executes each step, re-discovering elements per step from the live accessibility tree.

Rule #5 of the system prompt explicitly tells the model to skip auth-gated flows unless a visible signup or login form lets the test handle the gating itself. So for a marketing site or a logged-out landing page, the generator covers all the flows you care about. For a logged-in dashboard, you have two options. Option one: pass a URL that is already authenticated, by running the generator with `extension: true` against your own Chrome where you are signed in (server.ts handles the extension token plumbing). Option two: write the auth steps yourself as #Case 1 (3-4 lines), then let the generator append discovery cases for the post-login surface. The plan file is plain text. Adding three lines to the top is the same operation as editing any other Markdown file.

Because flows do not actually break when the UI changes. Locators do. The most common reason an end-to-end suite goes red is that someone renamed a data-testid, restructured a button into a div with role=button, or reordered fields in a form. The flow itself is unchanged; the user still wants to sign up. By writing intent in Markdown ('Click the Sign up button') rather than a locator string ('page.getByTestId("signup-cta-v3")'), the test stays decoupled from the markup. At runtime the agent re-binds the intent to whatever element matches in the current accessibility tree. When the markup changes, the test still passes if the user-visible behaviour still works. When the user-visible behaviour breaks, the test fails on something a human can read in plain English and act on without spelunking through a locator update.

Both work. The plan file is yours. You can keep running it through Assrt (which is the path of least resistance, since the same agent that wrote the file knows how to execute it) or you can hand-translate the Markdown into Playwright's own .spec.ts format and let your existing CI runner handle it. The full runner is open source: source code is in the repo, npm package is @m13v/assrt, and the CLI is `npx @m13v/assrt run --url <url> --plan <markdown>`. There is no vendor backend, no SaaS dashboard, no mandatory cloud. Run it on your laptop, run it in GitHub Actions, run it on a self-hosted Buildkite worker, the only network call is the one to the Anthropic API for the generation step, and if you set ANTHROPIC_BASE_URL you can point that at a local proxy or an air-gapped clone too.