agentleFS
Sign inStart free
leaf76leaf76/agent-skills/frontend-ui-guardrails/SKILL.md

frontend-ui-guardrails

Skill0 starsChanged 3 months agoMITView on GitHub

Use when frontend, UI, browser automation, live UI, screenshot, snapshot, responsive layout, accessibility, modal, form, navigation, or user-facing state work is in scope.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 9 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not expose technical details in user-facing messages.

    line 13
  2. Distinctive:

    Do not hardcode secrets, auth headers, environment-specific values, or profile-specific browser config.

    line 14
  3. Very specific:

    Prefer project-level agent-browser.json or AGENT_BROWSER_* environment variables when such config is already part of the project.

    line 15
  4. Distinctive:

    Web / browser UI: prefer Hermes Chrome (real cookies/SSO), then browser-e2e / agent-browser / Playwright headless / Chrome DevTools — not …

    line 19
  5. Distinctive:

    browser-use: only for external black-box sites (or explicit user request).

    line 20
  6. Very specific:

    Add a Playwright smoke flow only when a reproducible interaction or responsive regression check adds real value.

    line 24
  7. Very specific:

    Do not steal keyboard/mouse focus while the user works (osascript activate, headed Playwright, hijacking the active tab).

    line 25
  8. Distinctive:

    When a task includes screen evidence or responsive risk, check layout, spacing, alignment, centering, overflow, wrapping, clipping, …

    line 29
  9. Distinctive:

    Verify mobile and desktop primary breakpoints.

    line 30
  10. Very specific:

    Check text alignment, long text, dynamic content, localized strings, sticky/fixed/modal/overlay surfaces, corner controls, forms, keyboard …

    line 31
  11. Distinctive:

    Do not treat a desktop screenshot as proof that mobile works.

    line 37
  12. Distinctive:

    Do not change modal state logic, validation, routing, or copy while fixing a layout issue unless the task requires it.

    line 38
  13. Distinctive:

    Do not call a UI change done without browser or screenshot evidence when observable behavior was affected.

    line 39

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

Frontend UI Guardrails

This is a domain-specific expansion of the project's AGENTS.md (or equivalent agent rules). It may add frontend and UI requirements, but it must never weaken AGENTS.md, SECURITY, secrets handling, production safety, or destructive-command restrictions.

Core Rules

  • Preserve existing UI/UX behavior, accessibility, design system, copy, and interaction patterns unless the task explicitly requires a change.
  • Do not expose technical details in user-facing messages.
  • Do not hardcode secrets, auth headers, environment-specific values, or profile-specific browser config.
  • Prefer project-level agent-browser.json or AGENT_BROWSER_* environment variables when such config is already part of the project.

Evidence Priority

  • Web / browser UI: prefer Hermes Chrome (real cookies/SSO), then browser-e2e / agent-browser / Playwright headless / Chrome DevTools — not computer-use and not browser-use by default.
  • browser-use: only for external black-box sites (or explicit user request). Avoid full-auto for OTP, payments, production config, trading.
  • Native desktop shell only (Tauri / PyQt / Electron frame, tray, OS dialogs, file pickers) or explicit user request → computer-use skill (lazy-desktop-mcp). Announce before control; honor Presence STOP/PAUSE; do not use CU as a daily-Chrome driver.
  • Screenshot-only (no click/type) → screenshot skill.
  • Escalate to deeper DOM/console/network/performance tooling (Chrome DevTools) when more evidence is needed.
  • Add a Playwright smoke flow only when a reproducible interaction or responsive regression check adds real value.
  • Do not steal keyboard/mouse focus while the user works (osascript activate, headed Playwright, hijacking the active tab).

Layout And Interaction Checks

  • When a task includes screen evidence or responsive risk, check layout, spacing, alignment, centering, overflow, wrapping, clipping, safe-area, CTA visibility, and overlay obstruction.
  • Verify mobile and desktop primary breakpoints; include tablet when the component or flow can reasonably break there.
  • Check text alignment, long text, dynamic content, localized strings, sticky/fixed/modal/overlay surfaces, corner controls, forms, keyboard navigation, focus order, and focus visibility.
  • Cover loading, empty, error, disabled, and success states when they exist.
  • For layout review output, clearly separate evidence from static screenshots and evidence that still requires browser validation.

Common Mistakes

  • Do not treat a desktop screenshot as proof that mobile works.
  • Do not change modal state logic, validation, routing, or copy while fixing a layout issue unless the task requires it.
  • Do not call a UI change done without browser or screenshot evidence when observable behavior was affected.

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.

Check your setup, free