agentleFS
RaditteAnggoroRaditteAnggoro/skill-for-lazy-developer/.agents/skills/browser-diagnostics/SKILL.md

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.

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
  1. Distinctive:

    If browser control is unavailable, inspect relevant source and existing tests, provide a concrete reproduction/checklist, and clearly mark …

    line 16
  2. Distinctive:

    Follow the failing request or event into source code and server behaviour when accessible.

    line 22
  3. Distinctive:

    Do not change application records, replay payments, send messages, or use a personal browser profile as a side effect of testing without …

    line 30
  4. Distinctive:

    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 …

    line 34

≈ “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.

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

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.

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.

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.