SuperAPI AI Directory

chrome-browser-validation

Testing & quality

View repository

Updated 10-30 04:57

About this skill

Chrome browser acceptance

This is the user's global browser acceptance preference. It is applied automatically by default; only when the user explicitly requests another method, override it according to their current request.

Connect to existing Chrome

  • Use the official @Chrome extensionto reuse the user's existing Chrome session, login state, and target services.
  • Discover the Chrome extension connection through the currently provided browser runtime, and read the operation documentation it returns. If the tool is cua_repl, initialize it according to its first-call rules, then obtain the list of browsers and tabs. Confirm that the connection type is a Chrome extension, not a built-in browser or a session started on your own.
  • Select pages by target URL, title, and user-specified tab; prefer reusing existing relevant tabs. When a new page is needed, create it through the same Chrome extension connection and follow the runtime's session naming requirements. Do not modify unrelated tabs.
  • Do not launch standalone Playwright, headless Chrome, a standalone debugging port, Docker browser fixtures, or use AppleScript, native desktop control, or other browsers as a substitute for acceptance. Playwright-style locators provided by the extension runtime may be used; this does not equal launching a Playwright browser on your own.
  • If the extension is not connected, the target Chrome configuration is unavailable, or the connection is refused, report the specific obstacle and ask the user to complete the connection before continuing; do not silently fall back to another acceptance environment. Code checks that do not depend on the browser may continue.
  • Do not read, export, or transfer cookies, login tokens, or browser user data directories. When login is needed, the user performs it manually.

Accept on real pages

  1. Based on this change, determine the key display, interaction, and exception scenarios, and open or refresh the actual target page; for local web pages, prefer reusing the existing HTTP development service.
  2. Operate real controls based on the latest page state; re-read the state after each group of operations. Only use interfaces supported by the current runtime documentation, and do not guess tool capabilities.
  3. Verify results through page state and screenshots; do not claim visual acceptance is complete based only on a successful click, the existence of data, a successful compile, or passing tests. Content such as maps, Canvas, and WebGL must be checked against the actual rendered image.
  4. Check relevant errors using page, console, or network diagnostics supported by the extension; if these capabilities are unavailable, state which items were not checked, and do not open a separate browser to bypass this.
  5. Provide screenshots of key results and a brief conclusion, clearly distinguishing verified, failed, and unverified items. When the browser connection is blocked, do not reuse old screenshots as evidence for this acceptance.

This skill does not additionally authorize submissions, payments, sending messages, or other operations with external impact; execute within the scope authorized by the user's current task.