agentleFS
manastalukdarmanastalukdar/ai-devstudio/skills/browser-testing-with-devtools/SKILL.md

browser-testing-with-devtools

Skill1 starsChanged 7 months agoMITView on GitHub

Use Chrome DevTools MCP for live DOM inspection, console error capture, network request analysis, and paint profiling — runtime verification beyond what Playwright scripting covers.

61 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use constraint-driven-development, code-simplification and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MrCipherSmithSkill

    constraint-driven-development

    Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.

    Also in 12 projects that use this

  • HK-hubSkill

    code-simplification

    Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.

    Also in 34 projects that use this

  • VercelSkill

    web-design-guidelines

    Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".

    Also in 5 projects that use this

  • MicrosoftSkill

    playwright-cli

    Automate browser interactions, test web pages and work with Playwright tests.

    Also in 3 projects that use this

  • VercelSkill

    vercel-react-best-practices

    React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 55 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Early exit: If no issues are found in the initial snapshot, report "No issues detected" and stop

    line 18
  2. Distinctive:

    If not configured, report the requirement and stop.

    line 31
  3. Distinctive:

    Verify expected elements exist and are visible

    line 64
  4. Distinctive:

    Check ARIA roles, labels, and focus order for accessibility

    line 65
  5. Distinctive:

    Single-page app not fully hydrated: wait for network idle before inspecting.

    line 122

“Common” is measured: kept by at least 6 in 10 of the 55 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Browser Testing with DevTools

I'll connect to a running browser session and inspect it at runtime: DOM state, console errors, network traffic, and rendering performance. Requires Chrome DevTools MCP to be configured.

Arguments: $ARGUMENTS — URL to open or test to perform (e.g., "check login flow at http://localhost:3000")

Token Optimization

Expected range: 300–800 tokens per inspection (snapshot + analysis)

Early exit: If no issues are found in the initial snapshot, report "No issues detected" and stop

Patterns used: Progressive disclosure (summary first, full DOM/network only on specific request)

Prerequisites

Chrome DevTools MCP must be configured. Verify:

# Check if chrome-devtools-mcp is in MCP config
grep -r "devtools\|chrome" ~/.claude/settings.json .claude/settings.json 2>/dev/null | head -5

If not configured, report the requirement and stop.

Step 1 — Open or Connect to Page

Navigate to the target URL:

Navigate to: [URL from $ARGUMENTS or inferred from project]
Wait for: DOM ready / network idle

Take an initial snapshot of the page state (accessibility tree + title).

Step 2 — Console Error Scan

Capture all console messages:

Console output:
  errors:   [count]
  warnings: [count]
  logs:     [count]

Top errors (if any):
  [message] — [source file:line]

Any console.error or unhandled promise rejection is a test failure. Report immediately.

Step 3 — DOM Inspection

For the specific flow being tested, inspect the relevant DOM elements:

  • Verify expected elements exist and are visible
  • Check ARIA roles, labels, and focus order for accessibility
  • Confirm form inputs, buttons, and interactive elements are in the expected state
  • Flag any elements with display: none, visibility: hidden, or opacity: 0 that should be visible
DOM check:
  [element] — [found / not found / wrong state]
  [element] — [found / not found / wrong state]

Step 4 — Network Request Analysis

Review network requests made during the test flow:

Network:
  total requests: [N]
  failed (4xx/5xx): [N]
  slow (>500ms): [N]

Failed requests:
  [URL] — [status] — [response body excerpt]

Flag any unexpected 404s, 401s, CORS errors, or requests to the wrong environment.

Step 5 — Performance Snapshot

For pages where rendering performance matters:

Performance:
  FCP (First Contentful Paint): [N]ms — [good <1.8s / needs work / poor >3s]
  LCP (Largest Contentful Paint): [N]ms — [good <2.5s / needs work / poor >4s]
  Layout shifts: [N] — [stable / unstable]

Flag any Core Web Vitals that are in the "needs work" or "poor" range.

Step 6 — Report

Browser Test: [URL] — [PASS / FAIL]

Issues found: [N]
  [severity] [category]: [description]
  ...

Passed checks:
  - [check description]
  ...

Edge Cases

  • Chrome DevTools MCP not available: report the requirement; suggest using Playwright for automated testing instead
  • Page requires authentication: note the requirement; the user must provide a session cookie or perform login steps manually before calling this skill
  • Single-page app not fully hydrated: wait for network idle before inspecting; add explicit wait if hydration takes more than 2 seconds
  • Local dev server not running: detect via connection refused; report which server to start

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.