Browser Testing with DevTools
Use this skill to investigate, debug, and validate frontend behavior directly in a running browser session.
Contract
Use this skill to diagnose frontend issues using browser DevTools or the Claude in Chrome MCP, and to produce evidence-backed findings.
Do not use this skill for:
- Writing or running unit tests (use
vitest).
- Running Playwright/Cypress E2E test suites (use
playwright-cli).
- Debugging Node.js server-side code without a browser context.
Stop and report when the target page is inaccessible, the Chrome MCP is unavailable and the user cannot open a browser manually, or the issue requires backend/server access only.
Input Contract
Required:
- Target URL or running dev server address.
- Description of the symptom or behavior to investigate (error, wrong value, slow render, etc.).
Optional:
- Specific DevTools panel to focus on (Network, Console, Elements, Performance).
- Reproduction steps or expected vs. actual behavior.
- Feature branch or commit under test.
If required inputs are missing, ask for the URL and symptom before proceeding.
Output Contract
Return:
- Findings per panel used: what was observed, with screenshot or copied output as evidence.
- Root cause hypothesis with supporting evidence.
- Actionable next steps (code change, config fix, or further investigation needed).
- Any skipped checks and why.
Do not claim completion without captured evidence (screenshot, console output, or network log excerpt).
Workflow
Identify the investigation type — choose the primary angle:
- Network failure / unexpected request → Network panel
- JS error / unexpected value → Console panel
- Layout or style issue → Elements panel
- Slow render / jank → Performance panel
- Multiple angles → sequence them; start with Console for quick signal
Check MCP availability — attempt mcp__Claude_in_Chrome__list_connected_browsers. If connected, prefer MCP tools for automation. If not, guide the user to open DevTools manually and relay findings.
Execute the investigation — follow the relevant section in references/devtools-workflow.md. Capture all evidence before forming conclusions.
Form a root cause hypothesis — link observed data (status code, error message, layout offset, frame drop) to a specific cause in code or config.
Report findings — state what was observed, the hypothesis, and the next action. Include evidence inline (screenshot path, copied log line, or network payload excerpt).
Context Loading
Read when needed:
references/devtools-workflow.md: read for step-by-step panel procedures, MCP tool reference, and evidence capture patterns.
Do not load the reference at the start unless all four panels are in scope.
Red Flags
- Stating a root cause without captured evidence → go back and capture a screenshot or log line first.
- Opening all panels at once before narrowing the symptom → pick the most likely panel first; parallelism wastes time and dilutes focus.
- Skipping MCP availability check and going straight to manual instructions → check first; MCP is faster and produces structured output.
- Describing what DevTools "should show" without actually observing it → take a screenshot or read console output; hypotheticals are not evidence.
Anti-Rationalization
| Rationalization |
Reality |
| "The error is obvious, I don't need to open DevTools" |
A visible symptom rarely shows the root cause. One network request or one console line often contradicts the obvious explanation. |
| "The MCP tools are overkill for a quick check" |
One read_console_messages call is faster than guiding the user through F12 + copy-paste. Use the tool. |
| "I'll report findings without a screenshot to keep the response short" |
Unverified findings send developers in the wrong direction. A screenshot or log excerpt is the minimum bar. |
Validation
# Confirm MCP browser tools are available (run before starting)
# Expected: at least one connected browser listed, or clear "not connected" signal
# mcp__Claude_in_Chrome__list_connected_browsers
1---2name: browser-testing-with-devtools3description: Use when debugging or testing a frontend feature in a live browser: inspecting network requests, analyzing console errors, examining DOM state, profiling page performance, or running automated browser checks via Claude in Chrome MCP tools. Key terms: devtools, network tab, console error, DOM inspect, performance profile, browser debug, chrome, XHR, fetch, layout shift, memory leak.4---56# Browser Testing with DevTools78Use this skill to investigate, debug, and validate frontend behavior directly in a running browser session.910## Contract1112Use this skill to diagnose frontend issues using browser DevTools or the Claude in Chrome MCP, and to produce evidence-backed findings.1314Do not use this skill for:15- Writing or running unit tests (use `vitest`).16- Running Playwright/Cypress E2E test suites (use `playwright-cli`).17- Debugging Node.js server-side code without a browser context.1819Stop and report when the target page is inaccessible, the Chrome MCP is unavailable and the user cannot open a browser manually, or the issue requires backend/server access only.2021## Input Contract2223Required:24- Target URL or running dev server address.25- Description of the symptom or behavior to investigate (error, wrong value, slow render, etc.).2627Optional:28- Specific DevTools panel to focus on (Network, Console, Elements, Performance).29- Reproduction steps or expected vs. actual behavior.30- Feature branch or commit under test.3132If required inputs are missing, ask for the URL and symptom before proceeding.3334## Output Contract3536Return:37- Findings per panel used: what was observed, with screenshot or copied output as evidence.38- Root cause hypothesis with supporting evidence.39- Actionable next steps (code change, config fix, or further investigation needed).40- Any skipped checks and why.4142Do not claim completion without captured evidence (screenshot, console output, or network log excerpt).4344## Workflow45461. **Identify the investigation type** — choose the primary angle:47 - Network failure / unexpected request → Network panel48 - JS error / unexpected value → Console panel49 - Layout or style issue → Elements panel50 - Slow render / jank → Performance panel51 - Multiple angles → sequence them; start with Console for quick signal52532. **Check MCP availability** — attempt `mcp__Claude_in_Chrome__list_connected_browsers`. If connected, prefer MCP tools for automation. If not, guide the user to open DevTools manually and relay findings.54553. **Execute the investigation** — follow the relevant section in `references/devtools-workflow.md`. Capture all evidence before forming conclusions.56574. **Form a root cause hypothesis** — link observed data (status code, error message, layout offset, frame drop) to a specific cause in code or config.58595. **Report findings** — state what was observed, the hypothesis, and the next action. Include evidence inline (screenshot path, copied log line, or network payload excerpt).6061## Context Loading6263Read when needed:64- `references/devtools-workflow.md`: read for step-by-step panel procedures, MCP tool reference, and evidence capture patterns.6566Do not load the reference at the start unless all four panels are in scope.6768## Red Flags6970- Stating a root cause without captured evidence → go back and capture a screenshot or log line first.71- Opening all panels at once before narrowing the symptom → pick the most likely panel first; parallelism wastes time and dilutes focus.72- Skipping MCP availability check and going straight to manual instructions → check first; MCP is faster and produces structured output.73- Describing what DevTools "should show" without actually observing it → take a screenshot or read console output; hypotheticals are not evidence.7475## Anti-Rationalization7677| Rationalization | Reality |78|---|---|79| "The error is obvious, I don't need to open DevTools" | A visible symptom rarely shows the root cause. One network request or one console line often contradicts the obvious explanation. |80| "The MCP tools are overkill for a quick check" | One `read_console_messages` call is faster than guiding the user through F12 + copy-paste. Use the tool. |81| "I'll report findings without a screenshot to keep the response short" | Unverified findings send developers in the wrong direction. A screenshot or log excerpt is the minimum bar. |8283## Validation8485```bash86# Confirm MCP browser tools are available (run before starting)87# Expected: at least one connected browser listed, or clear "not connected" signal88# mcp__Claude_in_Chrome__list_connected_browsers89```9091- [ ] Target URL confirmed reachable (200 or expected redirect, not connection refused).92- [ ] Investigation type selected before opening any panel.93- [ ] At least one piece of captured evidence (screenshot, log line, network entry) is included in the report.94- [ ] Root cause hypothesis is explicitly linked to the captured evidence.95- [ ] Next action is concrete: a specific file, config key, or follow-up investigation.
jsonlee12138