Expect skill
A skill that tests your agent's code in a real browser: reads your changes, builds a test plan and runs it through Playwright with your own cookies
- 3,561 ★ on the repository
- Last commit
Broad access
Why this level
- By default the tool extracts your browser cookies and opens pages under your accounts; the --no-cookies flag turns that off
- The skill launches subagents and drives a browser: it clicks, fills forms and runs code on pages
- Installation uses an init script that the agent downloads from a website
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/expectDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- By default the tool extracts your browser cookies and opens pages under your accounts; the --no-cookies flag turns that off
- The skill launches subagents and drives a browser: it clicks, fills forms and runs code on pages
- Installation uses an init script that the agent downloads from a website
This is third-party code. Review the repository files before installing.
What it does
Expect is a skill and the expect-cli command-line tool from Million Software. It reads your git changes, builds a test plan from them and runs it in a real browser through Playwright. You start /expect inside Claude Code, Codex, GitHub Copilot, Gemini CLI, Cursor, OpenCode or Factory Droid, and Expect spins up subagents that act as real logged-in users. The agent fixes the problems found and reruns the check. The checks cover performance (long animation frames, INP, LCP), security (npm dependencies, CSRF, vulnerabilities), design (broken hover states, links and buttons) and app completeness (metadata, dead links). By default the browser opens in a window, with a headless mode, a connection to a running Chrome over CDP and reuse of a Chrome profile also available. The --ci flag and the add github-action command move the check into CI for every pull request.
Who it is for. For frontend developers and testers who edit a UI with an agent and want results checked in a browser without writing scripts.
Good fit when
- The agent edited a component or form and you need to confirm the page works in a browser
- You do not want to maintain selectors and assertions in Playwright or Cypress tests for each edit
- You need a run as a logged-in user with cookies from your browser
- Every pull request must be checked in CI automatically, in headless mode
- You want a quick check of LCP, INP, dead links and metadata on a new screen
Not a fit when
- You need to test a mobile app: mobile support has not shipped yet
- The test must run without access to your cookies: turn extraction off with --no-cookies or skip the tool
- You need a deterministic regression suite with fixed steps: the agent generates a plan for each change
- Your agent is not on the supported list: Expect detects it automatically among seven providers
Example request
/expect Check the sign-in form after my edits: validation errors, the redirect after login and dead links on the pageLimitations
The licence is FSL-1.1-MIT rather than plain MIT, so read its terms before commercial use. Mobile testing and a hosted version are announced as coming soon. An installed agent from the list is required: Claude Code, Codex, GitHub Copilot, Gemini CLI, Cursor, OpenCode or Droid. The result depends on the plan the model builds and on the state of your dev server. CI mode runs without cookies, auto-approves the plan and caps the run at 30 minutes.
How to disable. Delete the expect skill from your agent skills directory and remove the package with npm uninstall -g expect-cli if you installed it globally. Delete the GitHub Actions workflow from .github/workflows.
FAQ
How do I install Expect in Claude Code?
Ask the agent: "Fetch https://www.expect.dev/ and run init script". After installation the /expect command is available in a session of Claude Code, Codex or another supported agent.
How is Expect different from Playwright and Cypress?
With Playwright and Cypress you write scripts and maintain selectors and assertions. Expect reads your code changes, builds a test plan itself and runs it in a browser through Playwright. For a one-off check of an edit you write no test at all.
How is Expect different from computer-use agents?
General tools work from screenshots and mouse coordinates. Expect is built for testing: it drives the DOM quickly through Playwright, accounts for your changes, runs with your cookies and reports back what is broken.
Does Expect work in CI?
Yes. The --ci flag or the add github-action command runs the check headless without cookies, with the plan auto-approved and a 30-minute cap.
Which agent does Expect use when several are installed?
It detects the agents available on PATH and takes the first one found. The -a option picks a provider: claude, codex, copilot, gemini, cursor, opencode or droid.
Discussion
No questions or reviews yet.
Related
SkillsA skill that lets an agent write and run Playwright scripts: page tests, forms, screenshots and link checks
Playwright CLI
playwright-cli
Microsoft's official Playwright CLI with an agent skill: drive a browser through short commands without heavy MCP schemas
QA agents, skills and an MCP server: test generation, coverage gaps, flaky tests, security scans and chaos testing
An adversarial code-audit skill: Hunter finds bugs, Skeptic challenges them, Referee rules, and no source edit happens without your permission
MCP server, agent and skills for end-to-end UI tests where the agent drives the computer through vision on cloud machines
One binary for agent browser automation: a CLI with browser and check skills, an MCP server and clients for JS, Python and Java
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| Expect (this entry) | no | 3,561 | ||
| Playwright CLI | yes | 14,523 | the official Playwright CLI the agent uses to drive a browser; no change-based test plan | |
| BrowserTools MCP | no | not required | 7,330 | gives the agent the console, network and Lighthouse audits of an open Chrome but builds no tests itself |
README in short
The short intro calls Expect a skill for testing agent code in a browser and gives four steps to run it. Answers follow on the comparison with Playwright and computer-use agents, CI and mobile testing. Tables describe the command-line options and the seven supported agents with their install commands. The acknowledgements section credits the dev-browser project.
README badge
Original SKILL.md
---
name: expect
description: "Use when editing .tsx/.jsx/.css/.html, React components, pages, routes, forms, styles, or layouts. Also when asked to test, verify, validate, QA, find bugs, check for issues, or fix expect-cli failures."
license: MIT
metadata:
author: millionco
version: "2.4.0"
---
# Expect
You verify code changes in a real browser before claiming they work. No browser evidence, no completion claim.
Use the expect MCP tools (`open`, `playwright`, `screenshot`, etc.) for all browser interactions. Do not use raw browser tools (Playwright MCP, chrome tools, etc.) unless the user explicitly asks.
## Subagent Usage
Browser verification is best run in a subagent (Task tool) or background shell so the main thread stays free for code edits. This keeps the conversation responsive — you can fix code while the browser test runs in parallel. Strongly prefer launching a subagent for browser work, especially when the test involves multiple steps or long interactions. If the test is truly trivial (single screenshot check), inline is acceptable.
## Resuming Browser State
Before opening a new browser, check if one is already running. Use `browser_tabs` (action `list`) or the expect `screenshot` tool to see if a session is still active. If a tab is already open at the target URL, reuse it — don't close and reopen. When re-verifying after a code fix, prefer navigating or refreshing the existing session over starting from scratch.
## Compounding
The `playwright` tool takes a `code` string with `ref()` to resolve snapshot refs to Locators. One call can do an entire interaction — fills, clicks, AND data collection. Use that.
**BAD — 5 tool calls:**
```
screenshot (snapshot)
playwright: await ref('e3').fill('Jane')
screenshot (snapshot) ← WHY? page didn't change
playwright: await ref('e5').fill('jane@example.com')
playwright: await ref('e7').click()
```
**GOOD — 2 tool calls:**
```
screenshot (snapshot)
playwright (snapshotAfter=true):
await ref('e3').fill('Jane');
await ref('e5').fill('jane@example.com');
await ref('e7').click();