Devtools Site Testing

Overview

Load your own app in Chrome DevTools (MCP), confirm access and token persistence if you're behind a login or bot gate, run a perf trace, and report console/network failures with root-cause hints. This is a cross-platform way to actually load a page and see what happens, rather than reasoning from the code about whether it would load.

Prerequisites

This skill drives the chrome-devtools MCP server (tools like navigate_page, list_pages, take_screenshot, list_console_messages, performance_start_trace). If those tools aren't available in this session, the MCP server isn't configured — it typically runs a fresh, empty browser profile (never a copy of anyone's real logged-in Chrome profile; if you're setting this up yourself, don't point it at a personal profile either, since that would give every session access to whatever's logged in there).

If you ran /alignment-harness:harness-setup, it may have recorded your app's local URL and a way to sign in. If not, ask once:

• What's the URL your app runs at locally (and, if relevant, staging)?
• If you want signed-in flows tested, how do I sign in? (a dev-only auto-login route, or a test account you provide.) Anonymous/unauthenticated testing works with no answer here at all — say so plainly rather than guessing at credentials.

Workflow

1) Choose target URL

• Default to whatever local URL was recorded at setup (commonly http://localhost:3000/, but don't assume — use the recorded one, or ask).
• Treat production as unavailable unless the person confirms access and provides the exact host.
• If staging is unclear, ask for the exact host or check the project's own deployment config.

2) Reuse DevTools browser if already running

• If new_page returns the "browser already running" error, do not give up.
• Use list_pages → select_page on an existing tab, then navigate_page to your target URL.
• If you need a clean session, close extra tabs with close_page and reuse the remaining page.

3) Access-gate bypass (only if your staging/production sits behind one)

Some staging or production hosts sit behind a bot-check or access gate (Cloudflare and similar services often do this). If yours does, and you've set up a bypass (a token appended as a query param, a header, or a cookie), use it here:

• Load the page once with the bypass token/param, however your project defines it.
• Verify the resulting cookie or storage persists and the URL cleans itself (the token shouldn't linger in location.search).
• If the cookie is missing, check the browser console for logs from whatever component handles the bypass, and inspect that component's source.

Most projects don't have this — if yours doesn't, skip this step entirely.

4) Sign in (only if testing signed-in flows)

• Use whichever local login path you or the project set up (a dev-only auto-login route is common, or a real test account).
• If nothing is configured, test as an anonymous visitor and say so in your findings — don't guess at credentials or silently fail.

5) Smoke check the page

• Confirm key elements render (login form, buttons, nav).
• Note any layout breaks or disabled actions.

6) Capture console + network errors

• List console errors and their sources.
• Inspect failed network requests:
  • Status code, endpoint, method, and error (CORS vs 5xx vs blocked).
  • Preflight failures usually indicate API or CORS config issues.

7) Run performance trace

• Start a Performance trace with reload.
• Wait for the page to settle, then stop the trace.
• Report the key metrics (LCP, CLS, TBT/INP) and obvious bottlenecks.

8) Summarize findings

• Provide a short list of user-visible issues and likely causes.
• Separate access problems (gate/token/login) from backend/API failures.