diagnose-in-browser

Diagnose UI bugs in a real browser by reading console errors and measuring DOM state.

9|Updated Mar 4, 2026
One-click install
npx skills add https://github.com/timcsy/semorphe --skill diagnose-in-browser-timcsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: diagnose-in-browser
Source: https://github.com/timcsy/semorphe/tree/main/knowledge/skills/diagnose-in-browser
Command: npx skills add https://github.com/timcsy/semorphe --skill diagnose-in-browser-timcsy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a user reports that a UI "looks wrong", guessing from screenshots leads to wrong root-cause hypotheses and wasted fix attempts. This Skill enforces a disciplined browser-based diagnosis workflow that replaces pixel-level speculation with console errors, DOM measurements, and controlled experiments. ## Core Features & Use Cases - Console-first diagnosis: Read browser console messages before forming any hypothesis, including reloading the page to capture load-time errors. - DOM measurement over pixels: Use JavaScript to count elements, compare coordinates, and detect stacked or duplicated containers, producing quotable facts instead of impressions. - Controlled experiments: Revert your change and re-measure with the same script to prove whether a fix actually addresses the root cause. - Use Case: A Blockly toolbox shows overlapping blocks. Instead of guessing, you read the console, find a missing i18n key breaking block initialization, verify by reverting, then convert the lesson into an automated guardrail check. ## Quick Start Use the diagnose-in-browser skill to find the root cause of this UI glitch by reading the browser console and measuring the DOM instead of guessing from my screenshot.

Frequently Asked Questions about diagnose-in-browser

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I diagnose a UI bug without guessing from screenshots?

Open a real browser and read the console messages first, then measure DOM state with JavaScript to get positions, counts, and display values. Screenshot-based pixel inference has a high error rate, while the console often contains the exact error message and stack trace.

How to debug Blockly toolbox or flyout rendering problems?

Read the browser console for block definition errors such as messages not referencing all arguments, then count flyout containers in the DOM since stale duplicates can exist. Note that el.click() does not open Blockly categories; you must dispatch the full pointerdown/mousedown/pointerup/mouseup/click event sequence.

Why does the browser console show no errors on page load?

Console tracing only starts from the first call to the console-reading tool, so errors emitted during initial page load are missed. Reload the page after connecting the tool to capture load-time errors.

Why does my UI fix not change anything in the page?

Hot module replacement does not rebuild existing class instances, so code changes may not take effect until a full page reload. Also verify the served page title, since a 200 response can come from a different project running on the expected port.

How do I verify a UI fix actually addresses the root cause?

Run a controlled experiment: revert your change and re-measure with the exact same script. If the numbers are identical with and without the fix, the fix was neither the cause nor the solution, and you should keep tracing the stack rather than the symptom.