playwright-interactive

Playwright Interactive Skill

Use a persistent js_repl 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

• js_repl must be enabled for this skill.
• If js_repl is missing, enable it in ~/.codex/config.toml:

[features]
js_repl = true

• You can also start a new session with --enable js_repl (equivalent to -c features.js_repl=true).
• After enabling js_repl, 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 sandbox_mode=danger-full-access). This is a temporary requirement while js_repl + Playwright support inside the sandbox is still being completed.
• Run setup from the same project directory you need to debug.
• Treat js_repl_reset as a recovery tool, not routine cleanup. Resetting the kernel destroys your Playwright handles.

One-time setup

test -f package.json || npm init -y
npm install playwright
# Web-only, for headed Chromium or mobile emulation:
# npx playwright install chromium
# Electron-only, and only if the target workspace is the app itself:
# npm install --save-dev electron
node -e "import('playwright').then(() => console.log('playwright import ok')).catch((error) => { console.error(error); process.exit(1); })"

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.
   • If a requirement is visually central but subjective, convert it into an observable QA check instead of leaving it implicit.
   • Add at least 2 exploratory or off-happy-path scenarios that could expose fragile behavior.
2. Run the bootstrap cell once.
3. Start or confirm any required dev server in a persistent TTY session.
4. Launch the correct runtime and keep reusing the same Playwright handles.
5. After each code change, reload for renderer-only changes or relaunch for main-process/startup changes.
6. Run functional QA with normal user input.
7. Run a separate visual QA pass.
8. Verify viewport fit and capture the screenshots needed to support your claims.
9. Clean up the Playwright session only when the task is actually finished.