Here's what I found on the page.
Console errors
missing-logo.pngfailed to load (ERR_FILE_NOT_FOUND). The "Brew & Co logo" image is broken.fetchofapi/plans.jsonwas blocked by CORS, because the page is opened fromfile://and the origin isnull. The page logged "Failed to load plans: Failed to fetch". That failure is most likely a side effect of opening the page fromfile://, so serving it overhttp://should clear it.- One DevTools issue: an input has no
autocompleteattribute. - There was also a plain
page loadedlog.
Network requests (3 total)
index.htmlreturned 200.missing-logo.pngfailed withERR_FILE_NOT_FOUND.api/plans.jsonfailed withERR_FAILED, the CORS block above.
Performance trace (reload)
- LCP was 194 ms. TTFB was 0.2 ms, and the other ~194 ms was render delay.
- CLS was 0.00.
- There is no CrUX field data for this page.
- The trace surfaced only the LCPBreakdown insight, so I didn't dig into further insights. The long render delay is the one thing worth a closer look.
Form submission
I entered [email protected], selected "Monthly" and clicked Subscribe. The page then showed this text below the form:
Subscribed [email protected] to Monthly
The email appears in uppercase in that message, although I typed it in lowercase. The page may be transforming it with JavaScript or CSS, which is worth checking if that wasn't intended. The form fields kept their values ([email protected], Monthly).
I only used this local page and visited no other sites.
试用方式：我用 Google 的 chrome-devtools-mcp（关闭使用统计和 CrUX 上报，用 `--isolated --headless` 的临时干净浏览器，不碰你的日常 Chrome 和登录状态），让模型只操作我做的一个本地页面。页面里有故意放的问题：缺失的图片、一个会失败的请求、把邮箱转成大写的提交逻辑。模型找到了这些，并正确报告了表单提交后的页面文字。注意：这个 Skill 本身没有安全提示，它能操控真实浏览器。
What it does
Gives the model a playbook for the chrome-devtools MCP server. Tools are grouped into four sets: page management (open, navigate, switch and close pages, wait for text), input (click, fill forms, hover, press keys, drag, upload files, handle dialogs), debugging (accessibility-tree snapshots, screenshots, console messages, run JavaScript in the page, inspect network requests) and emulation and performance (resize, throttle CPU or network, record and analyse performance traces for Core Web Vitals).
How it works
- Snapshot first: take a text snapshot to get element uids, then click or fill by uid, and re-snapshot after page changes.
- Troubleshoot: check console errors, failed network requests, then evaluate scripts for specific values.
- Profile: start a trace with reload, then analyse insights such as LCP and layout shifts.
Good for
Debugging a page, checking performance, and automating browser steps on your own development sites.
High risk: it lets the model drive a real, running Chrome. That browser may be logged in to your accounts; the model can click, fill and submit forms, upload files, run any JavaScript in the page and read network requests (which may hold tokens and personal data), so it could act as you or leak data. The skill itself has no safety guidance. Use a separate clean profile with no logins, avoid live and financial sites, and watch what it does. Test-run with Google's chrome-devtools-mcp in a clean `--isolated --headless` browser on one local page: console, network, performance trace and form submit all worked and matched the problems I planted. By default the MCP sends usage statistics to Google and trace URLs to the CrUX API, checks for updates, and keeps a persistent profile; disable these with `--usageStatistics=false`, `--performanceCrux=false`, `--isolated`.