agentleFS
LiriRaidLiriRaid/waymark/skills/browser-verify/SKILL.md

browser-verify

Skill2 starsChanged 6 days agoMITView on GitHub

owner dept-qa. Verify a web change in a real browser: \"verifica que funcione\", \"pruébalo en el navegador\", \"se ve bien en móvil\", console errors, e2e.

  • Installs packages

We split this skill into the rules it gives an agent

9 rules. 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Look before you touch: Every interaction starts with a fresh view of the page (accessibility tree, text or screenshot).

    line 12
  2. Distinctive:

    Wait for readiness, not for time: Wait for the server to answer and for the page to settle (network quiet, target element present).

    line 13
  3. Distinctive:

    Use what the session already has: Prefer browser tools already wired into the session over installing anything.

    line 14
  4. Distinctive:

    MUST: stop servers you started and leave the user's running.

    line 23
  5. Very specific:

    SHOULD: keep scripts throwaway in the scratchpad.

    line 24
  6. Distinctive:

    Always return to the department:

    line 50
  7. Very specific:

    Before building, list patterns/ and read the matching file, if any (patterns/README.md explains the format).

    line 64
  8. Very specific:

    Update an existing pattern only with new, verified information (novelty check, waymark references/learning.md).

    line 66
  9. Distinctive:

    Read only the mode the task needs (one file).

    line 69

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “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 Verify

Precondition. Tool of dept-qa (supporting dept-frontend). If that department skill is not loaded in this conversation, load it first and use its brief (what, why, where, how) as the input of this skill. Skip only for L0 edits.

Approach

A passing test suite says the code compiles and the units behave; only a rendered page says the user can do the job. This skill turns the brief's acceptance criteria into observations in a real browser and returns evidence, not opinions.

  • Look before you touch. Every interaction starts with a fresh view of the page (accessibility tree, text or screenshot). Selectors and coordinates come from what is rendered now, never from guessing at the source.
  • Wait for readiness, not for time. Wait for the server to answer and for the page to settle (network quiet, target element present). Fixed sleeps are a last resort and always short.
  • Use what the session already has. Prefer browser tools already wired into the session over installing anything.
  • Local only, never credentials. Verify against localhost, 127.0.0.1, [::1], *.localhost or *.test, under the user already logged in on the platform: Waymark creates no test users or profiles and signs in nowhere. The one other host is a design-reference URL the user writes in the request, read-only. Never a production URL.
  • Every criterion gets a verdict. Pass, fail, or not verified with a reason. Silence is not a pass.

Guardrails

  • MUST recon before every interaction sequence; re-read after navigation or a re-render.
  • MUST stay on local development hosts; refuse production or third-party URLs for interaction.
  • MUST NOT type passwords, tokens, card or ID numbers anywhere: the user's own open session is the only login, and a screen that needs another is Ojos: no (<why>).
  • MUST NOT install browsers or packages without an explicit yes.
  • MUST stop servers you started and leave the user's running.
  • SHOULD keep scripts throwaway in the scratchpad; promote to a committed e2e test only when dept-qa asks for one.

Provider order

Decide once per session, top to bottom; stop at the first that works. Say which one was used in the output.

#ProviderHow to detectNotes
1ego-browser (the eyes' first provider)ego-browser on PATH (or ~/.local/share/ego/active_version_dir)Run ego-browser skill first and follow it. Scripts run in Node, not in the page: page.cdp("Emulation.setDeviceMetricsOverride", …) sets the viewport, page.evaluate measures, page.click clicks, page.screenshot({ path }) needs an absolute path; PowerShell: write a .mjs file. One task space per task, closed with finish({ keep: [] }). A version before 0.6.1 timed out on screenshots: upgrade, with the user's yes. Never a command that clears the profile.
2Built-in browser pane / preview toolsTool list or ToolSearch shows tools such as preview_start, navigate, read_page, find, computer (screenshot), read_console_messages, read_network_requests, resize_windowBest option: no install, the user can watch. resize_window takes presets (mobile 375, tablet 768, desktop) and a colorScheme for light/dark. Screenshots come back inline, not as files.
3Browser extension MCP (e.g. a Chrome extension server)Deferred tools named like mcp__<chrome-server>__navigate; load the whole set in ONE ToolSearch callRuns in the user's real browser profile: never read their other tabs, history or saved credentials.
4Playwright via Node@playwright/test or playwright in package.jsonpnpm exec playwright ... (or the project's package manager). Saves screenshots to disk.
5Playwright via Pythonplaywright in pyproject.toml / requirements*.txtUse the project's environment (uv run, poetry run, venv).
6Nothing available—Ask before installing anything (pnpm add -D @playwright/test + pnpm exec playwright install chromium). If the user declines, report every criterion as not verified and give manual steps.

Server lifecycle

Starting, reusing or stopping the dev server → references/server-lifecycle.md.

Inputs

InputSource
Briefthe dept-qa / dept-frontend brief: acceptance criteria, affected screens, states, viewports
Stack conventions../waymark/stacks/<stack>.md → Commands and Testing
Project context<project>/.waymark/memory.md → Quality gates (dev server row), Gotchas, test accounts
Known patternspatterns/ in this skill (generic flows) + project skills (project-specific)

Output contract

Always return to the department:

Browser verify · provider: <ego-browser | built-in pane | chrome MCP | playwright-node | playwright-python> · url: <local url> · server: <started by me / reused>
Criteria
- ✔ <criterion> — <what was observed>
- ✘ <criterion> — <observed vs expected> — <screenshot ref>
- not verified: <criterion> — <reason>
Console / network: <none new> | <level · message · source> | <failed request · status>
Screenshots: <paths or inline step refs>
Server: stopped / left running (not mine)

Pattern library (grows with use)

  • Before building, list patterns/ and read the matching file, if any (patterns/README.md explains the format).
  • After verifying a reusable flow that has no pattern yet (login with a seed user, a CRUD form, a modal, a paginated table, a theme toggle), write patterns/<pattern>.md from ../waymark/templates/pattern.template.md: intent, anatomy of the check, states to cover, a11y checks, pitfalls, one adapter per provider used. Project-specific routes and accounts go to project memory, not here.
  • Update an existing pattern only with new, verified information (novelty check, waymark references/learning.md).

Modes

Read only the mode the task needs (one file); never load all modes.

Pick the smallest mode that proves the brief. dept-qa browser verification for any UI change = smoke + the relevant parts of states + evidence.

  • smoke — any UI change; golden path of the changed feature. → modes/smoke.md
  • states — new or restyled components, screens with async data, responsive or theming work. → modes/states.md
  • regression — a previously reported bug was fixed, or a change touches code near a known bug. → modes/regression.md
  • evidence — closing an L1+ UI task, or the user asks for screenshots or console output. → modes/evidence.md
  • eyes — the end of every L2/L3 task that changes something seen, and of an L1 CSS/HTML change with no spec: automatic, the hook blocks the Cierre without it (ADR 0047). → modes/eyes.md

Stack adapters

Stack-specific notes → references/stack-adapters.md (read only the project's stack row).

Learned notes

Grows with use (waymark references/learning.md). Dated, non-obvious notes about using this tool. When there are more than ~10, fold them into the body above and clear this list.

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.