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
- Distinctive: line 12
Look before you touch: Every interaction starts with a fresh view of the page (accessibility tree, text or screenshot).
- Distinctive: line 13
Wait for readiness, not for time: Wait for the server to answer and for the page to settle (network quiet, target element present).
- Distinctive: line 14
Use what the session already has: Prefer browser tools already wired into the session over installing anything.
- Distinctive: line 23
MUST: stop servers you started and leave the user's running.
- Very specific: line 24
SHOULD: keep scripts throwaway in the scratchpad.
- Distinctive: line 50
Always return to the department:
- Very specific: line 64
Before building, list patterns/ and read the matching file, if any (patterns/README.md explains the format).
- Very specific: line 66
Update an existing pattern only with new, verified information (novelty check, waymark references/learning.md).
- Distinctive: line 69
Read only the mode the task needs (one file).
“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.
Files
Browser Verify
Precondition. Tool of
dept-qa(supportingdept-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],*.localhostor*.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-qaasks 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.
| # | Provider | How to detect | Notes |
| 1 | ego-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. |
| 2 | Built-in browser pane / preview tools | Tool list or ToolSearch shows tools such as preview_start, navigate, read_page, find, computer (screenshot), read_console_messages, read_network_requests, resize_window | Best 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. |
| 3 | Browser extension MCP (e.g. a Chrome extension server) | Deferred tools named like mcp__<chrome-server>__navigate; load the whole set in ONE ToolSearch call | Runs in the user's real browser profile: never read their other tabs, history or saved credentials. |
| 4 | Playwright via Node | @playwright/test or playwright in package.json | pnpm exec playwright ... (or the project's package manager). Saves screenshots to disk. |
| 5 | Playwright via Python | playwright in pyproject.toml / requirements*.txt | Use the project's environment (uv run, poetry run, venv). |
| 6 | Nothing 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
| Input | Source |
| Brief | the 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 patterns | patterns/ 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.mdexplains 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>.mdfrom../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.
Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
- Mr-Quin/danmaku-anywhere★ 549same name
- AndyForest/SoupNet★ 11same name
- chrisalehman/bionic★ 9same name
- aprameyak/coding-skills★ 1same name
- BlakeHastings/claude-code-artifacts★ 1same name
- Evan-Kim2028/agent-skills★ 1same name
- feelthefusion/skill-starter-kit★ 0same name
- Koshux/agentic-sdlc-scaffold★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- dept-architectureSkill
- dept-backendSkill
- dept-dataSkill
- dept-devexSkill
- dept-devopsSkill
- dept-frontendSkill
- dept-productSkill
- dept-qaSkill
- dept-securitySkill
- dept-ux-uiSkill
- library-docsSkill
- ui-auditSkill
- ui-buildSkill
- ui-refineSkill
- ui-systemSkill
- waymarkSkill
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.

