playwright

Overview of playwright skill

What this skill does

The playwright skill is for driving a real browser from the terminal with playwright-cli, especially when you need navigation, form filling, screenshots, snapshots, extraction, or UI-flow debugging. It is built for browser automation, not for writing test suites, and it favors a CLI-first workflow with a wrapper script that can run even when Playwright is not globally installed.

Who should install it

Install the playwright skill if you want reliable browser control without hand-writing a full automation stack. It is a good fit for agents that need to inspect live pages, reproduce user flows, collect page content, or debug interface behavior in a repeatable way.

What matters most

The main differentiator is the wrapper-based workflow: you check npx, set the skill path once, then use playwright-cli commands through PWCLI. That reduces setup friction and makes the skill practical for ad hoc automation, especially when the browser task is messy or the UI changes often.

How to Use playwright skill

Install and set the skill path

Use the skill install flow first:

npx skills add openai/skills --skill playwright

Then set the path once in your shell session or profile:

export CODEX_HOME="${CODEX_HOME:-$HOME/.codex}"
export PWCLI="$CODEX_HOME/skills/playwright/scripts/playwright_cli.sh"

Before doing anything else, verify npx exists. If it does not, install Node.js/npm first; the wrapper depends on it.

Turn a rough goal into a good prompt

Give the skill a concrete browser job, not a vague request. Better input includes the site, the target action, and the desired artifact.

Good prompt shape:

• “Use playwright skill to log into the staging app, navigate to the invoices page, and capture a screenshot of the filtered table.”
• “Use playwright for Browser Automation to open this URL, extract the visible product names, and report any console warnings.”
• “Use playwright skill to reproduce this signup error and capture a trace plus the final page state.”

This helps the skill choose the right commands, snapshots, and debugging steps.

Read these files first

For practical usage, start with:

• SKILL.md for the core workflow and constraints
• references/cli.md for command coverage
• references/workflows.md for interaction patterns and session usage
• scripts/playwright_cli.sh to understand how the wrapper resolves npx

If you are deciding whether the skill fits your environment, also skim agents/openai.yaml for the default intent and NOTICE.txt for provenance.

Practical workflow tips

Use the standard loop: open a page, snapshot, act on the element IDs, then snapshot again to confirm state changes. For form work, prefer fill over multiple keystrokes when you already know the field. For debugging, capture console, network, and tracing-start/tracing-stop around the failure instead of guessing.

playwright skill FAQ

Is playwright just a prompt, or a real installable workflow?

It is a real installable playwright skill with a wrapper script and reference commands, not just prompt text. That matters because the install gives you repeatable command structure, session handling, and a predictable entry point.

When should I not use playwright?

Do not use it if you only need static code generation, plain HTTP requests, or a test runner. It is also a poor fit if your environment cannot provide npx, because the wrapper will stop until Node.js/npm is available.

Is this beginner-friendly?

Yes, if your task is a browser task and you can describe the page and goal clearly. The main learning curve is not Playwright syntax; it is learning to ask for a specific browser outcome and then inspect snapshots before acting.

How is this different from @playwright/test?

Use this skill when you want CLI-driven browser automation. Use @playwright/test when you explicitly need test files, assertions, or a test harness. The skill is optimized for interactive use and live workflows, not a full testing project.

How to Improve playwright skill

Give better starting state

The best outputs come from inputs that name the URL, login state, device or viewport constraints, and the artifact you want back. If the task involves auth, say whether credentials already exist, whether MFA is expected, and whether the skill should stop after navigation or continue through submission.

Share the exact success criteria

Be specific about the end condition: “save a screenshot after the modal closes,” “extract the first 20 visible rows,” or “report any console errors after clicking Checkout.” This reduces unnecessary exploration and makes the playwright usage more deterministic.

Ask for the right debug artifacts

If the workflow is failing, request the evidence you need: snapshots for structure, screenshots for visual state, traces for interaction timing, and console/network output for runtime failures. These are much more useful than asking for a generic “fix the issue” run.

Avoid common failure modes

The most common mistake is under-specifying the UI path and over-specifying the implementation. Do not demand exact click counts if the page is likely to change; ask for the goal and let the skill navigate by current page state. Also avoid mixing browser automation with test-suite requirements unless you truly need @playwright/test.