- Home
- Skills
- Matthew Plusprogramming
- Monorepo
- Browser Test
browser-test_skill
- TypeScript
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill matthew-plusprogramming/monorepo --skill browser-test- SKILL.md15.3 KB
Overview
This skill executes browser-based UI testing using Chrome MCP tools to validate user interactions, visual outcomes, and navigation flows. It runs opinionated, reproducible tests against local, staging, or production smoke environments and captures evidence such as screenshots and DOM reads. Use it to verify UI acceptance criteria after implementation and security review, and to gate merges when visual or interaction behavior is required.
How this skill works
The skill loads atomic specs to extract UI acceptance criteria, opens fresh Chrome MCP tabs, and navigates to the target environment. It performs element discovery, user interactions (clicks, form input, keyboard), waits for outcomes, and verifies results via screenshots, DOM inspection, and JS evaluation. Failures are documented with evidence and a test-results manifest is written back to the spec group for traceability.
When to use it
- After UI component or page changes that affect user-visible behavior
- When testing user interaction flows (clicks, forms, modals, navigation)
- For visual features like toasts, animations, responsive layouts
- Before merge gates when a security review is complete and UI must be validated
- Optional: skip for backend-only or API-only changes
Best practices
- Run each test case in a fresh tab to avoid state pollution
- Prefer semantic selectors (text, role, aria-label) over brittle selectors
- Capture evidence before, during, and after interactions (screenshots and DOM)
- Wait for interactions to settle (explicit waits or element checks) rather than relying on fixed timings
- Reset test state between suites (clear storage or open new tab) and re-run failing tests to rule out flakiness
Example use cases
- Logout feature: verify logout button visibility, click behavior, redirect to /login, and confirmation toast
- Form submission: fill inputs, submit, verify success message and resulting navigation
- Modal flows: open modal, confirm action, verify dismissal and side effects
- Error handling: simulate network failure, verify error UI and retry controls
- Responsive checks: load pages at different viewports and verify layout and visibility
FAQ
Run locally for development and staging for integration. Use production only for non-destructive smoke tests.
What evidence should I include for failures?
Include screenshots of initial, interaction, and final states, DOM reads or JS results, steps to reproduce, and severity classification.