Test Playwright CLI skills while keeping your browser session
Start a browser skill review with a local page and an explicitly chosen browser session. Our Playwright CLI experiment completed 15 named observations: form controls, snapshot references, a mocked local response, motion preferences, a mobile viewport and individual tab cleanup. Seven existing browser tabs remained open. These results help you reproduce a small command workflow; they do not prove that an AI agent can execute the complete skill or that a real account login will succeed.
Choose the browser workflow you actually need
Microsoft Playwright CLI Browser Workflows provides terminal commands and reference documents for snapshots, forms, tabs, requests and debugging. The official source is pinned to commit b85c7a736bb473bf55b584e54a09ffa698d6d871 in our package. The original instructions and all ten task references are retained; BB Skills adds a separate scope preface and a reproducible local fixture.
| Need | Start with | Check first |
|---|---|---|
| Terminal commands with a live browser snapshot | Microsoft Playwright CLI | CLI version, existing session, selected executable and profile |
| A terminal browser workflow tailored to the coding environment | OpenAI Playwright | Its wrapper, installation requirements and environment-specific instructions |
| Persistent interactive browser debugging | OpenAI Playwright Interactive | Its required interactive runtime and browser state handling |
| A broader plan for testing a local web application | Anthropic Web Application Testing | Local server lifecycle, test target and evidence requirements |
These resources overlap in browser automation, but their execution interfaces differ. The experiment below exercised Microsoft CLI commands directly. It did not compare AI-client performance or establish a winner among the four resources.
Inspect the package before installing anything
The new package contains the original SKILL.md, complete reference documents, the upstream Apache 2.0 license, source mapping, file hashes and the independently written fixture. In the package viewer, inspect examples/native-browser-evidence.json and examples/run_cli_fixture.py together. A checksum identifies the downloaded bytes; it does not show that the instructions are suitable for your application.
The upstream skill uses the name playwright-cli, which is also the package’s top-level folder. Its BB Skills catalog URL uses microsoft-playwright-cli to distinguish the source. Preserve the original folder name when installing in a client that checks skill identity. Two apparent relative links in the documentation are illustrative generated artifacts, not omitted dependencies: an example snapshot and an example screenshot.
Download access and the included sources are free. Node.js, Python and a compatible browser are separate prerequisites. Review any package installation or runtime update before running it; no browser binary, logged-in account state or paid service is bundled.
Select the profile and understand the session name
A CLI session name selects a browser automation session. It does not by itself select your normal Chrome profile, preserve an existing login, or establish that two sessions are isolated. The actual launch or attachment configuration determines the executable and user data directory.
If you use a persistent Chrome profile, its user data directory is the root containing profile folders such as Default. The selected profile is configured separately. Review the executable path, user data root and profile argument before opening a session. If the selected profile is unavailable or locked, stop and resolve that condition instead of silently substituting another profile.
For this experiment, the runner used an already open, authorized persistent Chrome session. It opened only two local fixture tabs and closed those tabs individually. It did not launch another browser, copy a profile, export cookies, save authentication state or inspect account credentials. Preserving the seven existing tabs was observed during this run; persistence after browser or computer restart was not tested.
Reproduce the local command experiment
The recorded environment was Windows, Chrome 154, Playwright CLI 0.1.22, Node.js 24.10.0 and Python 3.12.4. The version numbers describe the recorded run, rather than a promise about newer versions. The upstream source’s package metadata also identifies CLI 0.1.22.
Review the fixture scripts, then start the local server from the extracted examples directory:
python serve_fixture.pyThe server listens on 127.0.0.1:8767 and serves only the synthetic example. In a second terminal, use your already configured and open CLI session:
python run_cli_fixture.py --cli-script /path/to/playwright-cli.js --session YOUR_EXISTING_SESSIONReplace the script path and session name with your own verified settings; use --node if Node requires an explicit executable path. The runner requires an existing session and does not open a fallback profile. It writes fixture snapshots and a screenshot under its output directory, then records the observations in native-browser-evidence.json. Stop the fixture server when you finish.
Read a fresh snapshot before choosing a target
The runner obtained accessible references from the local page’s snapshot, filled a synthetic display name, selected a native option, checked the local scope box and submitted the example. It then read the resulting status text. No remote account was created and no external form was submitted.
A reference is useful only in the context of the page snapshot that produced it. Navigation, changed content or remounted controls can invalidate the target you saw earlier. Refresh the snapshot and confirm the label before interacting. The fixture also attempted a deliberately missing reference and observed a CLI error. Treat that as an expected rejection, rather than a failure of the page or permission to force a click.
For a real application, review the target and requested action separately. Seeing a button does not establish authorization to purchase, publish, delete data or send a message. A failed observation after a submission also does not establish that the submission never happened; inspect the resulting page before retrying.
Separate mocked responses from server behavior
| Fixture | Observed result | Boundary |
|---|---|---|
| Local route mock | The page received a synthetic JSON idea through a CLI route | No third-party API or production server was tested |
| Route removed | The same page received the local server’s default idea | Restores this exact fixture route only |
| Reduced motion | The sample animation became none; clearing the override restored its baseline | One CSS sample, rather than an accessibility audit |
| Mobile width | The 390-pixel fixture viewport had no horizontal page overflow | One page and viewport; no cross-browser coverage |
| Tab cleanup | The two fixture tabs closed and seven existing tabs remained | No browser restart, login or cookie persistence test |
Mocking is useful for predictable interface states, but it cannot establish that a real API, authentication service or payment provider behaves the same way. Label mocked evidence explicitly and run authorized integration checks separately when those services become relevant.
Keep the scope attached to the evidence
The 15 observations are named in the evidence JSON, with the four fixture source hashes and recorded runtime versions. The downloadable package binds that evidence to the included source files and its own checksum. Its published practice record is a native browser command fixture; the catalog’s full skill runtime flag remains false.
This experiment excludes full AI-client execution, production-site testing, live account login, screenshots of private pages, cookie export, payment behavior and a comprehensive security or accessibility evaluation. It supports a specific reproducible command workflow. It does not certify the skill or predict every website’s behavior.
Sources, authorship and next steps
Microsoft authored the upstream CLI skill and documentation. BB Skills prepared this original guide, packaging notes and synthetic fixture with AI assistance. We inspected the pinned sources and checked actual command output before publication. We use the fixture to make the distinction between source review and observed behavior visible to readers.
Primary references: pinned official skill, upstream license, and Google’s guidance on useful content and transparent authorship. The last link explains our editorial approach; it is not an endorsement or a ranking guarantee.
Continue with the frontend and browser-testing selection guide, inspect the linked resource files, then reproduce the fixture in an environment you control before attempting your own application workflow.