Test automation for beginners, without picking a tool.

No. With Assrt the input is plain English inside a Markdown file. A single scenario is a line starting with #Case 1:, a short name, then 3-5 imperative sentences about what to click, what to type, and what to verify. You never import a test framework, never write a selector, never hand-roll a waitForElementVisible. If you are comfortable writing a Jira ticket or a bug report, you already know the dialect. Traditional tools (Cypress, Selenium, Playwright) do want a real language; that is a legitimate path, just not a required one.

It launches a local Chromium via Playwright MCP, navigates to the URL you gave it, scrolls through the page in three chunks, takes a screenshot and an accessibility snapshot at each position, then sends all three screenshots plus the first 8,000 characters of visible text to claude-haiku-4-5-20251001 with a system prompt that says 'generate 5-8 cases in #Case N: name format, keep each case self-contained, 3-5 actions max, verify only observable things.' The output is a markdown block you can either save to scenario.md and run with assrt_test, or edit in place. The full system prompt lives in assrt-mcp/src/mcp/server.ts at line 219.

For a signup form, assrt_plan will output something like: '#Case 1: Email signup succeeds with a disposable inbox. Navigate to /signup. Click the Sign up with email button. Type a disposable email into the email field. Press Continue. Wait for the verification code and paste it into the six-digit OTP field. Verify the URL changes to /app and the heading contains Welcome.' No setup blocks, no imports, no fixture files. Two to five sentences of imperative English. Assrt's own agent knows how to find the signup button because it calls snapshot() first and matches the text you wrote against the accessibility tree.

Four sections. assrt_diagnose takes the URL, the plan text, and the failure evidence, then sends it to the same Claude Haiku model with a system prompt that constrains the output to Root Cause (1-2 sentences), Analysis (3-5 sentences), Recommended Fix (concrete steps), and Corrected Test Scenario (a literal #Case N: block in the same format assrt_test consumes). The last section is the important one: you do not read a stack trace and infer the fix, you paste a complete new case into your scenario.md and re-run. The output contract is pinned in assrt-mcp/src/mcp/server.ts at line 240.

You skip: picking a framework, installing it, picking a language runtime, learning CSS selectors, learning XPath, learning the page object pattern, writing describe()/it() blocks, configuring a test runner, configuring a headless browser, wiring up fixtures, writing hand-tuned waits, reading HTML reports, reading selector timeout stack traces, and deciding which flows to cover on a brand-new app. You still need: an idea of what your app is supposed to do, and the willingness to eyeball the plan assrt_plan returned before you run it. Everything else is automated. This is not a claim that you will never need to know these things; it is a claim that you do not need to know any of them to run your first test.

Assrt does not emit a .spec.ts file you can commit next to your Cypress tests. The #Case Markdown file is the test. Under the hood the agent uses real Playwright MCP calls (navigate, click, type_text, snapshot, press_key) to drive a real Chromium, so the underlying execution is plain Playwright. If you outgrow the English format later and want full control, you can read the agent's tool-call transcript and port any scenario to a Playwright script by hand in an afternoon. Nothing about the data you create is locked to Assrt: plans are Markdown, results are JSON, videos are WebM.

Five to eight. The number is a hard constraint in the PLAN_SYSTEM_PROMPT at line 236 of assrt-mcp/src/mcp/server.ts: 'Generate 5-8 cases max, focused on the MOST IMPORTANT user flows visible on the page.' You can override the model (pass a different value in the tool call), but the count is baked into the prompt so that a beginner never gets back a 40-case plan they will not read. If you want more coverage, run assrt_plan on different URLs (signup page, pricing page, docs page) and concatenate.

Launching Claude with the Assrt MCP server registered is one npx command. Calling assrt_plan on a localhost URL typically returns a plan in 20 to 45 seconds (three screenshots plus model latency). Calling assrt_test on the resulting plan depends on what the test does: a simple homepage-loads case returns in 1-2 seconds, a signup flow with an email verification round-trip takes 25-30 seconds because of the real inbox poll. If a case fails, assrt_diagnose usually returns a corrected case in under 10 seconds. So the end-to-end first loop (generate a plan, run it, fix the one broken case) is usually in the 2-3 minute range, not the half-afternoon a traditional framework setup would cost.

The MCP server runs on your machine as a local Node process. The browser Assrt drives is a local Chromium started by Playwright. Plans, videos, and screenshots land in /tmp/assrt on your disk. The only remote call is to the Anthropic API for the model that reads the accessibility snapshot and writes the plan, which uses your own token. There is no Assrt cloud you have to sign up for to run the three tools. Compare that to hosted AI test platforms that charge $7,500 per month and require your production URL to be reachable from their cloud: the entire loop here is something you can run with an API key and a localhost URL, no outbound exposure of your app.

If you have nothing written yet, call assrt_plan with your app's URL. That returns a Markdown plan. Save it as scenario.md (or just pass the string straight to assrt_test). If you already know what you want to test, skip assrt_plan and call assrt_test directly with a plan you wrote. Only call assrt_diagnose after assrt_test reports a failure; it is the repair step, not an inspection step. The server's own instructions are explicit about this ordering and they ship with the MCP server so any connected Claude instance follows the same order without prompting.