web-testing
L2 AI-driven web UI testing for a React/Vite dashboard app. Originally authored against the Onsager Dashboard (the body's route table + file paths are Onsager-shaped); other React dashboards fork the procedure and substitute their own routes / test paths. Use when testing UI on PRs, triaging L1 test failures, or verifying UI behavior at desktop + mobile viewports. Triggers include "test the UI", "check the dashboard", "triage L1 failure", "run L2 tests", "validate this PR", "exploratory test the web app".
- Installs
- 61
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/onsager-ai/dev-skills --skill web-testing- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads web-testing automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Web Testing Protocol (L2)
Exploratory, AI-driven validation of dashboard UI changes — not regression testing. Regression coverage is L1's job (smoke + e2e suites under the dashboard's test directories). L2 catches things L1 misses: layout bugs, mobile regressions, interaction flows that only fail in a real browser.
Adopting in another repo: the procedure (read diff → map to routes → run agent-browser at two viewports → screenshot → verdict) is repo-agnostic. The route table, test paths, and verdict schema below are examples from
onsager-ai/onsager. Fork the skill and replace those concrete bits for your own dashboard.
When to invoke
- A PR touches
apps/dashboard/** - L1 e2e fails and you need to know if it's a real regression, flaky, or env
- Someone says "validate the UI" / "dogfood this change"
The app under test
The CI pipeline builds crates/stiglab/deploy/Dockerfile — a single image bundling the Rust backends (stiglab + synodic) and the prebuilt dashboard SPA. It listens on http://localhost:3000.
Primary routes:
| Route | Page | Heading |
|---|---|---|
/ | Factory overview | Factory |
/sessions | Sessions list | Sessions |
/sessions/:id | Session detail | — (dynamic) |
/nodes | Nodes list | Nodes |
/artifacts | Artifacts list | Artifacts |
/spine | Event spine viewer | — (dynamic) |
/governance | Governance | Governance |
/settings | Settings + credentials | Settings |
Viewports (always test both)
- Desktop:
agent-browser set viewport 1280 720 - Mobile:
agent-browser set viewport 375 812
Mobile matters — the dashboard ships with a responsive layout (see the md: breakpoints throughout). Horizontal overflow and hidden nav are the top-two regression classes.
Procedure
- Read the diff (
git diff $DIFF_RANGE) — you will receiveDIFF_RANGEas an env var from CI. - Map changes to routes. A change in
src/pages/SessionsPage.tsx⇒/sessions. A change insrc/components/layout/**⇒ every route. - For each affected route, at each viewport:
agent-browser open http://localhost:3000<route>- Snapshot the page; verify the heading + key elements render.
- Actively exercise interactive elements — don't just check markup:
- Click buttons, submit forms, open dialogs.
- Verify the result — did the UI state change, did the dialog close, did new data appear? Presence of markup is not proof of working.
- Check for layout bugs. On mobile especially: horizontal scroll is a failure; a nav that blocks content is a failure.
agent-browser screenshot --screenshot-dir /tmp/l2-screenshotsthen rename the output to{route-slug}-{desktop|mobile}.png.
- Crystallize findings. When you validate new behavior or catch a bug whose fix you can describe, write a deterministic L1 test under
apps/dashboard/tests/smoke/(component-level) orapps/dashboard/tests/e2e/(browser-level). This is how L2 discoveries become permanent L1 coverage. - Emit the verdict. Return JSON matching
tests/l2-verdict-schema.json:PASSif every affected route passes at both viewports.FAILif any route fails; include the specific failure inviewports[].issues[].
Triage mode
When invoked after an L1 e2e failure, your job is different:
- Read the failing test file(s) under
apps/dashboard/tests/e2e/. - Reproduce against
http://localhost:3000with agent-browser. - For each failure, classify: regression (real bug), flaky (intermittent / timing), or environment (test harness or CI issue).
- Return JSON matching
tests/l2-triage-schema.jsonwith root cause and suggested fix.
Guardrails
- Scope to the diff. Don't re-test the whole app on a one-line change.
- Screenshots are required evidence — no screenshot, the viewport didn't run.
- Don't invent routes. If a new route was added in the diff, use that one; otherwise stick to the table above.
- Keep it cheap. One browser session per viewport is plenty.
FAQ
What does the web-testing skill do?
L2 AI-driven web UI testing for a React/Vite dashboard app. Originally authored against the Onsager Dashboard (the body's route table + file paths are Onsager-shaped); other React dashboards fork the procedure and substitute their own routes / test paths. Use when testing UI on PRs, triaging L1 test failures, or verifying UI behavior at desktop + mobile viewports. Triggers include "test the UI", "check the dashboard", "triage L1 failure", "run L2 tests", "validate this PR", "exploratory test the web app".
How do I install web-testing?
Run npx skills add https://github.com/onsager-ai/dev-skills --skill web-testing in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/web-testing/ (personal) or .claude/skills/web-testing/ (project).
Which AI agents can use web-testing?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is web-testing safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains web-testing?
It is published by onsager-ai in onsager-ai/dev-skills. It has 61 recorded installs.
More from onsager-ai/dev-skills
codegraph
onsager-ai/dev-skills
Pre-indexed code knowledge graph (MCP, SQLite + tree-sitter) for faster, lower-token exploration of brownfield codebases. Use when starting work on a repo larger than 500 files or when the task involves cross-file traversal — "where is X used", "what calls Y", "what breaks if I change Z", "trace flow from A to B", "explain this subsystem". Skip for single-file edits or sessions shorter than the cold-start cost. Triggers include "codegraph", "code graph", "index this repo", "where is X defined", "find callers of", "callees of", "blast radius of changing X", "explore this codebase". Cuts the grep + Read loops needed to orient, via O(1) SQLite lookups and FTS5 search over 8 MCP tools — but it's an unsound tree-sitter approximation, so grep stays the completeness backstop for renames/exhaustive callers.
github-integration
onsager-ai/dev-skills
Enable the GitHub CLI (gh) in Claude Code cloud sessions and GitHub Copilot coding agent environments. Use this skill when: (1) setting up a project so cloud AI agents can use gh for PRs, issues, and releases, (2) configuring setup scripts or SessionStart hooks for gh installation, (3) adding copilot-setup-steps.yml for GitHub Copilot agents, (4) troubleshooting gh auth failures in cloud sessions, or (5) configuring GHTOKEN for headless environments. Triggers on: "enable gh", "github integration", "Claude Code cloud setup", "copilot setup steps", "gh auth in cloud", "gh not working in cloud", "setup script", or any request involving GitHub CLI access from cloud-based AI coding agents.
git-commit
onsager-ai/dev-skills
Best practices for creating clean, atomic git commits with good messages. Use when: (1) staging and committing changes, (2) writing commit messages, (3) deciding what to group in a single commit, (4) handling pre-commit hook failures, (5) choosing between amend and new commit. Triggers on "commit", "stage", "git add", "write a commit message", or "commit my changes".
agent-browser
onsager-ai/dev-skills
Open the skill to read its SKILL.md instructions.
issue-spec
onsager-ai/dev-skills
Create or revise a focused specification issue when explicitly requested or required by the repository contribution policy. Discover existing work, capture intent and acceptance criteria, and reconcile decisions before implementation.
plan-dag
onsager-ai/dev-skills
Render the current plan as a high-DPI PNG dependency DAG — nodes are issues / sub-issues / PRs, edges come from sub-issue links plus dependency-language prose ("Depends on", "Part of", "Blocks", "Closes") and PR / commit cross-references, and every node is color-coded done / in-progress / available-next / blocked so sequencing and critical path are obvious at a glance. Use when asked "plan as dag", "draw a dag", "dag diagram", "show the dependency graph", "what's blocking what", "what's the critical path", "what can be parallelized", "what's left for
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work