@yezack/chrome-devtools-mcp-108 0.0.0-stage → 1.10.2

package/skills/cookie-debugging/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: cookie-debugging
+description: Uses Chrome DevTools MCP for inspecting, debugging, and testing cookies, session state, authentication issues, and cookie consent compliance. Use when diagnosing 401/403 errors, authentication redirects, session expiration, Cookie/Set-Cookie header issues, cookie banner consent conformance, or third-party cookie/SameSite/Partitioned cookie warnings.
+---
+
+## Core Concepts
+
+### HttpOnly vs Client-Side Storage
+
+Cookies marked `HttpOnly` cannot be accessed or modified by client-side JavaScript (`cookieStore` or `document.cookie`). However, the browser **automatically attaches active HttpOnly cookies to outgoing HTTP request headers (`Cookie`)**.
+
+- To inspect current `HttpOnly` values: Look at the `Cookie` request header of any outgoing HTTP request via `get_network_request`.
+- To inspect how cookies were created or configured: Look at the `Set-Cookie` response header of login/auth responses.
+- To inspect non-`HttpOnly` cookies: Use `evaluate_script` with the modern `cookieStore` API (`async () => await cookieStore.getAll()`).
+
+### Session Strategy: Live Tab vs Isolated Context
+
+Choose the right session environment to avoid state contamination (e.g., residual analytics or auth tokens):
+
+| Strategy                            | When to Use                                                                   | Setup / Teardown                                                                                              |
+| :---------------------------------- | :---------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------ |
+| **Live Tab (Active Page)**          | Diagnosing an active user session, live 401/403 error, or current state.      | Operates directly on the currently selected page.                                                             |
+| **Clean-Slate (`isolatedContext`)** | Testing cookie consent banners, first-time visits, or zero-cookie guarantees. | Call `new_page` with a unique `isolatedContext` (e.g. `"consent-audit-1"`). When finished, call `close_page`. |
+
+### Client-Side Capabilities & Limitations
+
+| Action                                                           | Client JavaScript (`cookieStore` / `document.cookie`) | DevTools Network & Context Tools                        |
+| :--------------------------------------------------------------- | :---------------------------------------------------- | :------------------------------------------------------ |
+| **Read Non-HttpOnly**                                            | ✅ `async () => await cookieStore.getAll()`           | ✅ `get_network_request` (Request `Cookie`)             |
+| **Read HttpOnly**                                                | ❌ Blocked by browser security                        | ✅ `get_network_request` (Request `Cookie`)             |
+| **Inspect Attributes** (`Domain`, `Path`, `SameSite`, `Expires`) | ✅ `async () => await cookieStore.getAll()`           | ✅ `get_network_request` (Response `Set-Cookie`)        |
+| **Modify / Delete Non-HttpOnly**                                 | ✅ `async () => await cookieStore.set(...)`           | N/A                                                     |
+| **Modify / Delete HttpOnly**                                     | ❌ **Silent failure** in JavaScript                   | ✅ Use `new_page(isolatedContext: ...)` for clean state |
+
+> [!WARNING]
+> Attempting to clear an `HttpOnly` cookie via JavaScript (`cookieStore.delete` or `document.cookie = "...; max-age=0"`) will silently fail. To test in an unauthenticated or fresh state, always spawn a new isolated context using `new_page` with `isolatedContext`.
+
+---
+
+## Workflow Patterns
+
+### 1. Diagnosing Authentication Failures & Redirects (401 / 403)
+
+When an authenticated page request fails, returns 401/403, or redirects to login:
+
+1. **List Recent Requests**: Call `list_network_requests` with `includePreservedRequests: true`.
+2. **Find the Target Request**: Locate the failing request (401/403) or redirect (302/307).
+3. **Inspect Outgoing `Cookie` Header**: Call `get_network_request` with the `reqid`.
+   - Verify if the `Cookie` header was attached and whether required tokens (e.g. `SESSION_ID`, `auth_token`) were sent.
+4. **Trigger Active Inspection (If no recent request exists)**:
+   - If the cookie was set in a previous session and no network call is listed, trigger a request:
+     - Use `navigate_page` with `reload: true`, OR
+     - Call `evaluate_script` with `() => fetch(window.location.href)`
+   - Then call `get_network_request` on the new request to inspect the active `Cookie` header.
+5. **Trace the Setting Request**: If the cookie is missing or rejected:
+   - Check earlier login/handshake responses for `Set-Cookie` directives:
+     - **Path mismatch**: e.g., `Path=/api` when the request is to `/`.
+     - **Domain mismatch**: e.g., `Domain=api.example.com` preventing cookies on `sub.example.com`.
+     - **Secure flag on HTTP**: `Secure` cookies are never sent over unencrypted `http://`.
+     - **SameSite blocking**: `SameSite=Strict` cookies are omitted on cross-site navigations.
+     - **Expiration**: Check if `Expires` or `Max-Age` elapsed.
+
+### 2. Cookie Banner & Consent Conformance Testing
+
+To verify that no non-essential or tracking cookies are set before consent or when declining:
+
+1. **Start Clean**: Open a fresh isolated context with a dedicated name:
+   ```json
+   {"url": "<PAGE_URL>", "isolatedContext": "consent-test-1"}
+   ```
+2. **Record Baseline Cookies**: Before interacting with the banner, run `evaluate_script` with `async () => await cookieStore.getAll()`.
+3. **Inspect Premature Network Requests & Issues**:
+   - Call `list_network_requests` to ensure no third-party tracking beacons fired before consent.
+   - Call `list_console_messages` with `types: ["issue"]` to check for tracking warnings.
+4. **Interact with Consent Banner**:
+   - Capture snapshot with `take_snapshot` to locate the "Decline" or "Reject All" button `uid`.
+   - Click the button with `click`.
+5. **Verify Cookie Difference**:
+   - Run `evaluate_script` with `async () => await cookieStore.getAll()` after clicking to assert that only strictly necessary or consent-state cookies exist.
+6. **Test Consent Revocation (Lifecycle Audit)**:
+   - When auditing consent withdrawal or preference changes:
+     - Locate and click the "Cookie Settings", "Manage Preferences", or footer privacy trigger (`take_snapshot` $\rightarrow$ `click`).
+     - Deselect non-essential categories or click "Revoke All" / "Save Preferences".
+     - Re-query `cookieStore.getAll()` to verify previously accepted non-essential cookies were cleared or expired.
+     - Call `list_network_requests` on subsequent actions to ensure tracking beacons are no longer fired.
+7. **Teardown Context**: Call `close_page` when the audit is complete to prevent leftover cookies from affecting subsequent tasks.
+
+### 3. Auditing Cookie Security, SameSite & CHIPS (Partitioned Cookies)
+
+1. **Fast-Track: Native DevTools Issues (Recommended)**:
+   - Call `list_console_messages` with:
+     ```json
+     {
+       "types": ["issue"],
+       "includePreservedMessages": true
+     }
+     ```
+   - Check for `CookieIssue` entries, such as:
+     - `SameSiteNoneInsecure`: `SameSite=None` without `Secure`.
+     - `ThirdPartyCookiePhaseout`: Third-party cookie blocked or restricted.
+     - `SchemefulSameSite`: Cross-scheme cookie issues.
+     - `PartitionedCookies`: Invalid CHIPS partitioning attributes.
+2. **Deep Audit: Lighthouse Third-Party Cookies**:
+   - Run `lighthouse_audit` with `mode: "navigation"` and `outputDirPath: "/tmp/lh-report"`.
+   - **Extract the specific cookie audit** without loading the full report into context:
+     ```bash
+     node -e "const r=require('/tmp/lh-report/report.json'); const a=r.audits['third-party-cookies']; console.log(JSON.stringify({score: a?.score, displayValue: a?.displayValue, items: a?.details?.items}))"
+     ```
+
+### 4. Client-Side Cookie Inspection & Manipulation
+
+For client-accessible, non-`HttpOnly` cookies (e.g., UI preferences, non-sensitive feature flags):
+
+1. **Read Cookies & Attributes**:
+   - Use the modern asynchronous Cookie Store API:
+     ```js
+     async () => await cookieStore.getAll();
+     ```
+   - _Fallback for insecure HTTP origins_: `() => document.cookie`.
+2. **Set / Modify Cookie**:
+   - Set client cookie via `cookieStore`:
+     ```js
+     async () =>
+       await cookieStore.set({
+         name: 'theme',
+         value: 'dark',
+         expires: Date.now() + 86400000,
+         sameSite: 'lax',
+       });
+     ```
+3. **Delete Cookie**:
+   - Clear client cookie:
+     ```js
+     async () => await cookieStore.delete('theme');
+     ```
+
+---
+
+## Troubleshooting
+
+- **`cookieStore` is undefined**: `cookieStore` requires a Secure Context (`https://`, `localhost`, or `127.0.0.1`). On non-secure HTTP origins, use `() => document.cookie` or test over HTTPS.
+- **`evaluate_script` returns empty / unresolved Promise**: `cookieStore` methods are asynchronous. Always wrap calls with `async () => await cookieStore.getAll()`.
+- **Cookie not visible in JavaScript**: The cookie is marked `HttpOnly`. Trigger a network request and call `get_network_request` to view it in the `Cookie` request header.
+- **JavaScript deletion did not remove cookie**: The cookie is `HttpOnly` or requires matching `Path` and `Domain` parameters. Use a fresh `isolatedContext` with `new_page` for a clean slate.
+- **Cookie set in response but not sent in requests**:
+  - Verify if page is `http://` while cookie specifies `Secure`.
+  - Check if `Domain` restricts subdomains.
+  - Check `list_console_messages(types: ["issue"])` for browser rejection reasons.
+- **Residual cookies contaminating audits**: Always use `new_page` with a unique `isolatedContext` when running compliance tests, and call `close_page` when done.

package/skills/debug-optimize-lcp/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: debug-optimize-lcp
+description: Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions "largest contentful paint", "page load speed", "CWV", or wants to improve how fast their hero image or main content renders.
+---
+
+## What is LCP and why it matters
+
+Largest Contentful Paint (LCP) measures how quickly a page's main content becomes visible. It's the time from navigation start until the largest image or text block renders in the viewport.
+
+- **Good**: 2.5 seconds or less
+- **Needs improvement**: 2.5–4.0 seconds
+- **Poor**: greater than 4.0 seconds
+
+LCP is a Core Web Vital that directly affects user experience and search ranking. On 73% of mobile pages, the LCP element is an image.
+
+## LCP Subparts Breakdown
+
+Every page's LCP breaks down into four sequential subparts with no gaps or overlaps. Understanding which subpart is the bottleneck is the key to effective optimization.
+
+| Subpart                       | Ideal % of LCP | What it measures                               |
+| ----------------------------- | -------------- | ---------------------------------------------- |
+| **Time to First Byte (TTFB)** | ~40%           | Navigation start → first byte of HTML received |
+| **Resource load delay**       | <10%           | TTFB → browser starts loading the LCP resource |
+| **Resource load duration**    | ~40%           | Time to download the LCP resource              |
+| **Element render delay**      | <10%           | LCP resource downloaded → LCP element rendered |
+
+The "delay" subparts should be as close to zero as possible. If either delay subpart is large relative to the total LCP, that's the first place to optimize.
+
+**Common Pitfall**: Optimizing one subpart (like compressing an image to reduce load duration) without checking others. If render delay is the real bottleneck, a smaller image won't help — the saved time just shifts to render delay.
+
+## Debugging Workflow
+
+Follow these steps in order. Each step builds on the previous one.
+
+### Step 1: Record a Performance Trace
+
+Navigate to the page, then record a trace with reload to capture the full page load including LCP:
+
+1. `navigate_page` with `pageId` to the target URL.
+2. `performance_start_trace` with `pageId`, `reload: true` and `autoStop: true`.
+
+The trace results will include LCP timing and available insight sets. Note the insight set IDs from the output — you'll need them in the next step.
+
+### Step 2: Analyze LCP Insights
+
+Use `performance_analyze_insight` to drill into LCP-specific insights. Look for these insight names in the trace results:
+
+- **LCPBreakdown** — Shows the four LCP subparts with timing for each.
+- **DocumentLatency** — Server response time issues affecting TTFB.
+- **RenderBlocking** — Resources blocking the LCP element from rendering.
+- **LCPDiscovery** — Whether the LCP resource was discoverable early.
+
+Call `performance_analyze_insight` with `pageId`, the insight set ID, and the insight name from the trace results.
+
+### Step 3: Identify the LCP Element
+
+Use `evaluate_script` (with `pageId`) and the **"Identify LCP Element" snippet** found in [references/lcp-snippets.md](references/lcp-snippets.md) to reveal the LCP element's tag, resource URL, and raw timing data.
+
+The `url` field tells you what resource to look for in the network waterfall. If `url` is empty, the LCP element is text-based (no resource to load).
+
+### Step 4: Check the Network Waterfall
+
+Use `list_network_requests` to see when the LCP resource loaded relative to other resources:
+
+- Call `list_network_requests` with `pageId` filtered by `resourceTypes: ["Image", "Font"]` (adjust based on Step 3).
+- Then use `get_network_request` with `pageId` and the LCP resource's request ID for full details.
+
+**Key Checks:**
+
+- **Start Time**: Compare against the HTML document and the first resource. If the LCP resource starts much later than the first resource, there's resource load delay to eliminate.
+- **Duration**: A large resource load duration suggests the file is too big or the server is slow.
+
+### Step 5: Inspect HTML for Common Issues
+
+Use `evaluate_script` (with `pageId`) and the **"Audit Common Issues" snippet** found in [references/lcp-snippets.md](references/lcp-snippets.md) to check for lazy-loaded images in the viewport, missing fetchpriority, and render-blocking scripts.
+
+## Optimization Strategies
+
+After identifying the bottleneck subpart, apply these prioritized fixes.
+
+### 1. Eliminate Resource Load Delay (target: <10%)
+
+The most common bottleneck. The LCP resource should start loading immediately.
+
+- **Root Cause**: LCP image loaded via JS/CSS, `data-src` usage, or `loading="lazy"`.
+- **Fix**: Use standard `<img>` with `src`. **Never** lazy-load the LCP image.
+- **Fix**: Add `<link rel="preload" fetchpriority="high">` if the image isn't discoverable in HTML.
+- **Fix**: Add `fetchpriority="high"` to the LCP `<img>` tag.
+
+### 2. Eliminate Element Render Delay (target: <10%)
+
+The element should render immediately after loading.
+
+- **Root Cause**: Large stylesheets, synchronous scripts in `<head>`, or main thread blocking.
+- **Fix**: Inline critical CSS, defer non-critical CSS/JS.
+- **Fix**: Break up long tasks blocking the main thread.
+- **Fix**: Use Server-Side Rendering (SSR) so the element exists in initial HTML.
+
+### 3. Reduce Resource Load Duration (target: ~40%)
+
+Make the resource smaller or faster to deliver.
+
+- **Fix**: Use modern formats (WebP, AVIF) and responsive images (`srcset`).
+- **Fix**: Serve from a CDN.
+- **Fix**: Set `Cache-Control` headers.
+- **Fix**: Use `font-display: swap` if LCP is text blocked by a web font.
+
+### 4. Reduce TTFB (target: ~40%)
+
+The HTML document itself takes too long to arrive.
+
+- **Fix**: Minimize redirects and optimize server response time.
+- **Fix**: Cache HTML at the edge (CDN).
+- **Fix**: Ensure pages are eligible for back/forward cache (bfcache).
+
+## Verifying Fixes & Emulation
+
+- **Verification**: Re-run the trace (`performance_start_trace` with `pageId` and `reload: true`) and compare the new subpart breakdown. The bottleneck should shrink.
+- **Emulation**: Lab measurements differ from real-world experience. Use `emulate` to test under constraints:
+  - `emulate` with `pageId`, `networkConditions: "Fast 3G"` and `cpuThrottlingRate: 4`.
+  - This surfaces issues visible only on slower connections/devices.

package/skills/debug-optimize-lcp/references/elements-and-size.md

@@ -0,0 +1,27 @@
+# Elements and Size for LCP
+
+## What Elements are Considered?
+
+The types of elements considered for Largest Contentful Paint (LCP) are:
+
+- **`<img>` elements**: The first frame presentation time is used for animated content like GIFs.
+- **`<image>` elements** inside an `<svg>` element.
+- **`<video>` elements**: The poster image load time or first frame presentation time, whichever is earlier.
+- **Background images**: Elements with a background image loaded using `url()`.
+- **Block-level elements**: Containing text nodes or other inline-level text element children.
+
+## Heuristics to Exclude Non-Contentful Elements
+
+Chromium-based browsers use heuristics to exclude:
+
+- Elements with **opacity of 0**.
+- Elements that **cover the full viewport** (likely background).
+- **Placeholder images** or low-entropy images.
+
+## How is an Element's Size Determined?
+
+- **Visible Area**: Typically the size visible within the viewport. Extending outside, clipped, or overflow portions don't count.
+- **Image Elements**: Either the visible size or the intrinsic size, whichever is smaller.
+- **Text Elements**: The smallest rectangle containing all text nodes.
+- **Exclusions**: Margin, padding, and borders are not considered toward the size.
+- **Containment**: Every text node belongs to its closest block-level ancestor element.

package/skills/debug-optimize-lcp/references/lcp-breakdown.md

@@ -0,0 +1,23 @@
+# Largest Contentful Paint (LCP) Breakdown
+
+LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport. To provide a good user experience, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits.
+
+## The Four Subparts of LCP
+
+Every page's LCP consists of these four subcategories. There's no gap or overlap between them, and they add up to the full LCP time.
+
+| LCP subpart                   | % of LCP (Optimal) | Description                                                                                                                                                              |
+| ----------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Time to First Byte (TTFB)** | ~40%               | The time from when the user initiates loading the page until the browser receives the first byte of the HTML document response.                                          |
+| **Resource load delay**       | <10%               | The time between TTFB and when the browser starts loading the LCP resource. If the LCP element doesn't require a resource load (e.g., system font text), this time is 0. |
+| **Resource load duration**    | ~40%               | The duration of time it takes to load the LCP resource itself. If the LCP element doesn't require a resource load, this time is 0.                                       |
+| **Element render delay**      | <10%               | The time between when the LCP resource finishes loading and the LCP element rendering fully.                                                                             |
+
+## Why the Breakdown Matters
+
+Optimizing for LCP requires identifying which of these subparts is the bottleneck:
+
+- **Large delta between TTFB and FCP**: Indicates the browser needs to download a lot of render-blocking assets or complete a lot of work (e.g., client-side rendering).
+- **Large delta between FCP and LCP**: Indicates the LCP resource is not immediately available for the browser to prioritize or the browser is completing other work before it can display the LCP content.
+- **Large resource load delay**: Indicates the resource is not discoverable early or is deprioritized.
+- **Large element render delay**: Indicates rendering is blocked by stylesheets, scripts, or long tasks.

package/skills/debug-optimize-lcp/references/lcp-snippets.md

@@ -0,0 +1,79 @@
+# LCP Debugging Snippets
+
+Use these JavaScript snippets with the `evaluate_script` tool to extract deep insights from the page.
+
+## 1. Identify LCP Element
+
+Use this snippet to identify the LCP element and get raw timing data from the Performance API.
+
+```javascript
+async () => {
+  return await new Promise(resolve => {
+    new PerformanceObserver(list => {
+      const entries = list.getEntries();
+      const last = entries[entries.length - 1];
+      resolve({
+        element: last.element?.tagName,
+        id: last.element?.id,
+        className: last.element?.className,
+        url: last.url,
+        startTime: last.startTime,
+        renderTime: last.renderTime,
+        loadTime: last.loadTime,
+        size: last.size,
+      });
+    }).observe({type: 'largest-contentful-paint', buffered: true});
+  });
+};
+```
+
+## 2. Audit Common Issues
+
+Use this snippet to check for common DOM-based LCP issues (lazy loading, priority).
+
+```javascript
+() => {
+  const issues = [];
+
+  // Check for lazy-loaded images in viewport
+  document.querySelectorAll('img[loading="lazy"]').forEach(img => {
+    const rect = img.getBoundingClientRect();
+    if (rect.top < window.innerHeight) {
+      issues.push({
+        issue: 'lazy-loaded image in viewport',
+        element: img.outerHTML.substring(0, 200),
+        fix: 'Remove loading="lazy" from this image — it is in the initial viewport and may be the LCP element',
+      });
+    }
+  });
+
+  // Check for LCP-candidate images missing fetchpriority
+  document.querySelectorAll('img:not([fetchpriority])').forEach(img => {
+    const rect = img.getBoundingClientRect();
+    if (rect.top < window.innerHeight && rect.width * rect.height > 50000) {
+      issues.push({
+        issue: 'large viewport image without fetchpriority',
+        element: img.outerHTML.substring(0, 200),
+        fix: 'Add fetchpriority="high" to this image — it is large and visible in the initial viewport',
+      });
+    }
+  });
+
+  // Check for render-blocking scripts in head
+  document
+    .querySelectorAll(
+      'head script:not([async]):not([defer]):not([type="module"])',
+    )
+    .forEach(script => {
+      if (script.src) {
+        issues.push({
+          issue: 'render-blocking script in head',
+          element: script.outerHTML.substring(0, 200),
+          fix: 'Add async or defer attribute, or move to end of body',
+        });
+      }
+    });
+
+  return {issueCount: issues.length, issues};
+};
+```

package/skills/debug-optimize-lcp/references/optimization-strategies.md

@@ -0,0 +1,38 @@
+# LCP Optimization Strategies
+
+## 1. Eliminate Resource Load Delay
+
+**Goal**: Ensure the LCP resource starts loading as early as possible.
+
+- **Early Discovery**: Ensure the LCP resource is discoverable in the initial HTML document response (not dynamically added by JS or hidden in `data-src`).
+- **Preload**: Use `<link rel="preload">` with `fetchpriority="high"` for critical images or fonts.
+- **Avoid Lazy Loading**: Never set `loading="lazy"` on the LCP image.
+- **Fetch Priority**: Use `fetchpriority="high"` on the `<img>` tag.
+- **Same Origin**: Host critical resources on the same origin or use `<link rel="preconnect">`.
+
+## 2. Eliminate Element Render Delay
+
+**Goal**: Ensure the LCP element can render immediately after its resource has finished loading.
+
+- **Minimize Render-Blocking CSS**: Inline critical CSS and defer non-critical CSS. Ensure the stylesheet is smaller than the LCP resource.
+- **Minimize Render-Blocking JS**: Avoid synchronous scripts in the `<head>`. Inline very small scripts.
+- **Server-Side Rendering (SSR)**: Deliver the full HTML markup from the server so image resources are discoverable immediately.
+- **Break Up Long Tasks**: Prevent large JavaScript tasks from blocking the main thread during rendering.
+
+## 3. Reduce Resource Load Duration
+
+**Goal**: Reduce the time spent transferring the bytes of the resource.
+
+- **Optimize Resource Size**: Serve optimal image sizes, use modern formats (AVIF, WebP), and compress images/fonts.
+- **Geographic Proximity (CDN)**: Use a Content Delivery Network to get servers closer to users.
+- **Reduce Contention**: Use `fetchpriority="high"` to prevent lower-priority resources from competing for bandwidth.
+- **Caching**: Use efficient `Cache-Control` policies.
+
+## 4. Reduce Time to First Byte (TTFB)
+
+**Goal**: Deliver the initial HTML as quickly as possible.
+
+- **Minimize Redirects**: Avoid multiple redirects from advertisements or shortened links.
+- **CDN Caching**: Cache static HTML documents at the edge.
+- **Edge Computing**: Move dynamic logic to the edge to avoid trips to the origin server.
+- **Back/Forward Cache**: Ensure pages are eligible for bfcache.

package/skills/memory-leak-debugging/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: memory-leak-debugging
+description: Diagnoses and resolves memory leaks in JavaScript/Node.js applications. Use when a user reports high memory usage, OOM errors, or wants to capture, compare, or inspect heap snapshots with Chrome DevTools MCP memory tools.
+---
+
+# Memory Leak Debugging
+
+This skill provides expert guidance and workflows for finding, diagnosing, and fixing memory leaks in JavaScript and Node.js applications using Chrome DevTools MCP tools.
+
+## Prerequisites
+
+Advanced memory debugging tools (`compare_heapsnapshots`, `get_heapsnapshot_details`, etc.) are only available when the server is started with the `--memoryDebugging` flag. First check if these tools are available; if not, try to read the MCP configuration file to check if `--memoryDebugging` is enabled.
+
+## Core Principles
+
+- **Prefer MCP memory tools:** Do NOT attempt to read raw `.heapsnapshot` files directly, as they are extremely large and will consume too many tokens. Use the Chrome DevTools MCP heap snapshot tools to summarize, compare, and inspect snapshots.
+- **Isolate the Leak:** Determine if the leak is in the browser (client-side) or Node.js (server-side).
+- **Common Culprits:** Look for detached DOM nodes, unhandled closures, global variables, event listeners not being removed, and caches growing unbounded. _Note: Detached DOM nodes are sometimes intentional caches; always ask the user before nulling them._
+- **Close Loaded Snapshots:** Heap snapshots can be large. After completing an investigation, use `close_heapsnapshot` for each loaded snapshot to release memory held by the MCP server.
+
+## Workflows
+
+### 1. Capturing Snapshots
+
+When investigating a frontend web application memory leak, utilize the `chrome-devtools-mcp` tools to interact with the application and take snapshots.
+
+- Use page-scoped tools like `click`, `navigate_page`, `fill`, etc. (specifying `pageId`) to manipulate the page into the desired state.
+- Revert the page back to the original state after interactions to see if memory is released.
+- Repeat the same user interactions 10 times to amplify the leak.
+- Use `take_heapsnapshot` (with `pageId`) to save `.heapsnapshot` files to disk at baseline, target (after actions), and final (after reverting actions) states.
+
+### 2. Comparing Snapshots
+
+Once you have generated `.heapsnapshot` files using `take_heapsnapshot`, compare them with Chrome DevTools MCP memory tools.
+
+- Start with `get_heapsnapshot_summary` for each snapshot to confirm that the files load and to compare high-level totals.
+- Use `compare_heapsnapshots` to compare baseline and target snapshots. Start without `classIndex` for the summary diff, then request detailed class diffs only for suspicious growth by specifying `classIndex`.
+- Use the summary output from `compare_heapsnapshots` before drilling into specific node IDs.
+
+### 3. Inspecting Retainers and Dominator Chains
+
+When a class or object type grows unexpectedly, inspect the retaining chain and dominators with the MCP tools before changing code.
+
+- Use `get_heapsnapshot_class_nodes` to list instances of the suspicious class.
+- Use `get_heapsnapshot_retainers`, `get_heapsnapshot_retaining_paths`, `get_heapsnapshot_dominators`, and `get_heapsnapshot_edges` to understand why representative nodes are still reachable.
+- Use `get_heapsnapshot_object_details` with a specific `nodeId` to retrieve detailed object metadata (size, type, distance, and DOM detachedness).
+- Use `get_heapsnapshot_duplicate_strings` when string growth dominates the diff.
+- Read [references/common-leaks.md](references/common-leaks.md) for examples of common memory leaks and how to fix them after the retaining path points at application code.
+
+### 4. Advanced Analysis and Categorized Filters
+
+Use built-in MCP memory tools and filters to pinpoint specific leak categories directly without external tools.
+
+- Use `get_heapsnapshot_details` or `get_heapsnapshot_class_nodes` with `filterName` to target common leak causes:
+  - `objectsRetainedByDetachedDomNodes`: Identifies detached DOM elements retained in memory.
+  - `objectsRetainedByEventHandlers`: Identifies objects kept alive by unremoved event listeners.
+  - `objectsRetainedByContexts`: Identifies objects trapped in closures or execution contexts.
+  - `objectsRetainedByConsole`: Identifies objects retained by console logging.

package/skills/memory-leak-debugging/references/common-leaks.md

@@ -0,0 +1,33 @@
+# Common Memory Leaks
+
+When analyzing retaining paths, dominator chains, or class diffs with Chrome DevTools MCP memory tools, look for these common patterns in the codebase:
+
+## 1. Uncleared Event Listeners
+
+Event listeners attached to global objects (like `window` or `document`) or long-living objects prevent garbage collection of the objects referenced in their callbacks.
+
+**Fix:** Always call `removeEventListener` when a component unmounts or the listener is no longer needed.
+
+## 2. Detached DOM Nodes
+
+A DOM node is removed from the document tree but is still referenced by a JavaScript variable. While detachedness is a good signal for a memory leak, it's not always a bug. For example, websites sometimes intentionally cache detached navigation trees.
+
+**Fix:** Signal the detached nodes to the user first. **Ask the user first** before nulling the references or changing the code, as the detached nodes might be part of an intentional cache. If confirmed as a leak, ensure variables holding DOM references are set to `null` when the node is removed, or limit their scope.
+
+## 3. Unintentional Global Variables
+
+Variables declared without `var`, `let`, or `const` (in non-strict mode) or explicitly attached to `window` remain in memory forever.
+
+**Fix:** Use strict mode, properly declare variables, and avoid global state.
+
+## 4. Closures
+
+Closures can unintentionally keep references to large objects in their outer scope.
+
+**Fix:** Nullify large objects when they are no longer needed, or refactor the closure to not capture unnecessary variables.
+
+## 5. Unbounded Caches or Arrays
+
+Data structures used for caching (like objects, Arrays, or Maps) that grow without limits.
+
+**Fix:** Implement caching limits, use LRU caches, or use `WeakMap`/`WeakSet` for data associated with object lifecycles.

package/skills/troubleshooting/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: troubleshooting
+description: Uses Chrome DevTools MCP and documentation to troubleshoot connection and target issues. Trigger this skill when list_pages, new_page, or navigate_page fail, or when the server initialization fails.
+---
+
+## Troubleshooting Wizard
+
+You are acting as a troubleshooting wizard to help the user configure and fix their Chrome DevTools MCP server setup. When this skill is triggered (e.g., because `list_pages`, `new_page`, or `navigate_page` failed, or the server wouldn't start), follow this step-by-step diagnostic process:
+
+### Step 1: Find and Read Configuration
+
+Your first action should be to locate and read the MCP configuration file. Search for the following files in the user's workspace: `.mcp.json`, `gemini-extension.json`, `.claude/settings.json`, `.vscode/launch.json`, or `.gemini/settings.json`.
+
+If you find a configuration file, read and interpret it to identify potential issues such as:
+
+- Incorrect arguments or flags.
+- Missing environment variables.
+- Usage of `--autoConnect` in incompatible environments.
+
+If you cannot find any of these files, only then should you ask the user to provide their configuration file content.
+
+### Step 2: Triage Common Connection Errors
+
+Before reading documentation or suggesting configuration changes, check if the error message matches one of the following common patterns.
+
+#### Error: `Could not find DevToolsActivePort`
+
+This error is highly specific to the `--autoConnect` feature. It means the MCP server cannot find the file created by a running, debuggable Chrome instance. This is not a generic connection failure.
+
+Your primary goal is to guide the user to ensure Chrome is running and properly configured. Do not immediately suggest switching to `--browserUrl`. Follow this exact sequence:
+
+1. **Ask the user to confirm that the correct Chrome version** (e.g., "Chrome Canary" if the error mentions it) is currently running.
+2. **If the user confirms it is running, instruct them to enable remote debugging.** Be very specific about the URL and the action: "Please open a new tab in Chrome, navigate to `chrome://inspect/#remote-debugging`, and make sure the 'Enable remote debugging' checkbox is checked."
+3. **Once the user confirms both steps, your only next action should be to call the `list_pages` tool.** This is the simplest and safest way to verify if the connection is now successful. Do not retry the original, more complex command yet.
+4. **If `list_pages` succeeds, the problem is resolved.** If it still fails with the same error, then you can proceed to the more advanced steps like suggesting `--browserUrl` or checking for sandboxing issues.
+
+#### Symptom: Server starts but creates a new empty profile
+
+If the server starts successfully but `list_pages` returns an empty list or creates a new profile instead of connecting to the existing Chrome instance, check for typos in the arguments.
+
+- **Check for flag typos:** For example, `--autoBronnect` instead of `--autoConnect`.
+- **Verify the configuration:** Ensure the arguments match the expected flags exactly.
+
+#### Symptom: Missing Tools / Only 9 tools available
+
+If the server starts successfully but only a limited subset of tools (like `list_pages`, `get_console_message`, `lighthouse_audit`, `take_heapsnapshot`) are available, this is likely because the MCP client is enforcing a **read-only mode**.
+
+All tools in `chrome-devtools-mcp` are annotated with `readOnlyHint: true` (for safe, non-modifying tools) or `readOnlyHint: false` (for tools that modify browser state, like `emulate`, `click`, `navigate_page`). To access the full suite of tools, the user must disable read-only mode in their MCP client (e.g., by exiting "Plan Mode" in Gemini CLI or adjusting their client's tool safety settings).
+
+#### Symptom: Extension tools are missing or extensions fail to load
+
+If the tools related to extensions (like `install_extension`) are not available, or if the extensions you load are not functioning:
+
+1. **Check for the `--categoryExtensions` flag**: Ensure this flag is passed in the MCP server configuration to enable the extension category tools.
+2. **Make sure the MCP server in configured to launch Chrome instead of connecting to an instance**: Chrome before 149 is not able to load extensions when connecting to an existing instance (`--auto-connect`, `--browserUrl`).
+
+#### Other Common Errors
+
+Identify other error messages from the failed tool call or the MCP initialization logs:
+
+- `Target closed`
+- "Tool not found" (check if they are using `--slim` which only enables navigation and screenshot tools).
+- Missing `pageId`: Page-scoped tools require a `pageId` argument. Call `list_pages` to find active page IDs.
+- `ProtocolError: Network.enable timed out` or `The socket connection was closed unexpectedly`
+- `Error [ERR_MODULE_NOT_FOUND]: Cannot find module`
+- Any sandboxing or host validation errors.
+
+### Step 3: Read Known Issues
+
+Read the contents of https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md to map the error to a known issue. Pay close attention to:
+
+- Sandboxing restrictions (macOS Seatbelt, Linux containers).
+- WSL requirements.
+- `--autoConnect` handshakes, timeouts, and requirements (requires **running** Chrome 144+).
+
+### Step 4: Formulate a Configuration
+
+Based on the exact error and the user's environment (OS, MCP client), formulate the correct MCP configuration snippet. Check if they need to:
+
+- Pass `--browser-url=http://127.0.0.1:9222` instead of `--autoConnect` (e.g. if they are in a sandboxed environment like Claude Desktop).
+- Enable remote debugging in Chrome (`chrome://inspect/#remote-debugging`) and accept the connection prompt. **Ask the user to verify this is enabled if using `--autoConnect`.**
+- Add `--logFile <absolute_path_to_log_file>` to capture debug logs for analysis.
+- Increase `startup_timeout_ms` (e.g. to 20000) if using Codex on Windows.
+
+_If you are unsure of the user's configuration, ask the user to provide their current MCP server JSON configuration._
+
+### Step 5: Run Diagnostic Commands
+
+If the issue is still unclear, run diagnostic commands to test the server directly:
+
+- Run `npx chrome-devtools-mcp@latest --help` to verify the installation and Node.js environment.
+- If you need more information, run `DEBUG=* npx chrome-devtools-mcp@latest --logFile=/tmp/cdm-test.log` to capture verbose logs. Analyze the output for errors.
+
+### Step 6: Check GitHub for Existing Issues
+
+If https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md does not cover the specific error, check if the `gh` (GitHub CLI) tool is available in the environment. If so, search the GitHub repository for similar issues:
+`gh issue list --repo ChromeDevTools/chrome-devtools-mcp --search "<error snippet>" --state all`
+
+Alternatively, you can recommend that the user checks https://github.com/ChromeDevTools/chrome-devtools-mcp/issues and https://github.com/ChromeDevTools/chrome-devtools-mcp/discussions for help.