Agent skill · software engineering · openai
playwright-interactive
Persistent browser and Electron interaction through `js_repl` for fast iterative UI debugging.
Why this skill is useful
Adds specific commands and workflows for persistent Playwright debugging that are not commonly known or documented.
What it needs
Requires electron, playwright installed locally. About 12k tokens when loaded. Last updated 2026-07-14. 24,594 stars on the source repository.
What this skill does
Playwright Interactive Skill Use a persistent jsrepl Playwright session to debug local web or Electron apps, keep the same handles alive across iterations, and run functional plus visual QA without restarting the whole toolchain unless the process ownership changed. Preconditions jsrepl must be enabled for this skill. If jsrepl is missing, enable it in ~/.codex/config.toml: You can also start a new session with --enable jsrepl (equivalent to -c features.jsrepl=true). After enabling jsrepl, start a new Codex session so the tool list refreshes. For now, run this workflow with sandboxing disabled: start Codex with --sandbox danger-full-access (or the equivalent config for sandboxmode=danger-full-access). This is a temporary requirement while jsrepl + Playwright support inside the sandbox is still being completed. Run setup from the same project directory you need to debug. Treat jsreplreset as a recovery tool, not routine cleanup. Resetting the kernel destroys your Playwright handles. One-time setup If you switch to a different workspace later, repeat setup there. Core Workflow 1. Write a brief QA inventory before testing: Build the inventory from three sources: the user's requested requirements, the user-visible features or behaviors you actually implemented, and the claims you expect to make in the final response. Anything that appears in any of those three sources must map to at least one QA check before signoff. List the user-visible claims you intend to sign off on. List every meaningful user-facing control, mode switch, or implemented interactive behavior. List the state changes or view changes each control or implemented behavior can cause. Use this as the shared coverage list for both functional QA and visual QA. For each claim or control-state pair, note the intended functional check, the specific state where the visual check must happen, and the evidence you expect to capture. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills openai/playwright-interactive