browser-diagnostics
Skill1 starsChanged 7 days agoMITView on GitHub
Reproduce web UI failures using browser console, network, DOM, rendering, or performance evidence. Use when behaviour must be observed in a browser, not for ordinary static UI edits.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adaptive-workflowSkill
- architecture-mapSkill
- domain-modelingSkill
- feature-discoverySkill
- lean-senior-engineeringSkill
- release-readinessSkill
- research-plan-implementSkill
- skill-security-guardSkill
- spec-to-code-verificationSkill
- systematic-debuggingSkill
- transaction-safe-engineeringSkill
- ui-design-intelligenceSkill
- ui-implementationSkill
- ui-quality-verificationSkill
- verification-before-completionSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
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
- Distinctive: line 16
If browser control is unavailable, inspect relevant source and existing tests, provide a concrete reproduction/checklist, and clearly mark …
- Distinctive: line 22
Follow the failing request or event into source code and server behaviour when accessible.
- Distinctive: line 30
Do not change application records, replay payments, send messages, or use a personal browser profile as a side effect of testing without …
- Distinctive: line 34
Use this skill when an interface or browser flow has an unexplained failure and you need to reproduce it, isolate the cause, and verify a …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Browser Diagnostics
Inspect the requested web behaviour in a development or user-authorized test environment. This skill supplies a workflow; it does not install or provide a browser tool.
Establish capabilities and target
Discover available browser/DevTools tools and existing browser-test scripts. Use the connected browser tool or the repository's configured automation. Do not invent tool names or assume Chrome DevTools MCP is installed.
Confirm the target URL from project configuration or the user. Inspect a start script before launching it. Prefer a separate development browser context with test data. Record relevant browser, route, viewport, and authentication setup without copying session tokens.
If browser control is unavailable, inspect relevant source and existing tests, provide a concrete reproduction/checklist, and clearly mark live UI verification as not performed. Never treat static reasoning or a mock response as a browser run.
Reproduce and diagnose
Exercise the smallest interaction sequence that shows the problem. Capture expected and actual state, relevant console errors and failed requests, response status, and a screenshot when useful. Redact sensitive fields from saved evidence. Wait for explicit UI or network state rather than arbitrary delays.
Follow the failing request or event into source code and server behaviour when accessible. A failed request may originate in the client, proxy, server, or external dependency; inspect evidence before assigning the cause. Browser success does not prove server authorization or database correctness.
For performance questions, record a trace or use existing measurements. State cache condition, environment, workload, and baseline. Do not infer a speedup from a smaller bundle or subjective responsiveness alone.
Fix and verify within the request
For diagnosis-only requests, report evidence and fix direction. For requested fixes, implement the responsible change, rerun the original interaction, and add a stable regression test through the existing framework when valuable. Include relevant empty/error states and keyboard interaction where affected.
Do not change application records, replay payments, send messages, or use a personal browser profile as a side effect of testing without relevant authorization. A browser connection can expose real data and perform real actions.
Boundary with UI quality verification
Use this skill when an interface or browser flow has an unexplained failure and you
need to reproduce it, isolate the cause, and verify a fix. Use
ui-quality-verification for a planned visual, responsive, keyboard, state, or
accessibility audit of a working interface. Do not duplicate a full quality audit here;
once the failure is understood, hand a requested broader audit to that skill.
Handoff
Report reproduction steps, supported cause, changes if made, browser results, and remaining gaps. Distinguish browser checks from backend checks and performance measurements.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

