New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

UI QA Sweep

by LanternOps in LanternOps/breeze

Broad regression QA of the Breeze RMM web UI via Playwright — exercising everyday MSP workflows and setup tasks like a human QA tester, logging functional PASS/FAIL plus UI/UX observations, and…

AGPL-3.0Auto-check: notesTesting & QA

Install UI QA Sweep

skills CLI
$ npx skills add LanternOps/breeze --skill ui-qa-sweep -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install LanternOps/breeze ui-qa-sweep --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/LanternOps/breeze.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/ui-qa-sweep .claude/skills/ui-qa-sweep && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
ui-qa-sweep
GitHub stars
131
Token cost
~3k tokens
SKILL.md length
1,480 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Broad regression QA of the Breeze RMM web UI via Playwright — exercising everyday MSP workflows and setup tasks like a human QA tester, logging functional PASS/FAIL plus UI/UX observations, and…

  • Works in 5 steps: Environment (read this first, it always… → Baseline login + nav crawl → Everyday-workflow checklist → …
  • Asks to QA the UI
  • SKILL.md covers Purpose & scope, Workflow, Phase 1 — Environment (read… and Phase 2 — Baseline login + nav…, plus 6 more sections
  • Calls gh, docker and pnpm; reaches 2breeze.app; needs E2E_ADMIN_PASSWORD

What it does

UI QA Sweep is an agent skill from LanternOps/breeze. Broad regression QA of the Breeze RMM web UI via Playwright — exercising everyday MSP workflows and setup tasks like a human QA tester, logging functional PASS/FAIL plus UI/UX observations, and filing GitHub issues from findings. Use this whenever the user asks to "QA the UI", do "extensive UI testing", a "regression sweep", "test everyday flows", "act as QA", verify recently/previously merged PRs end-to-end through the browser, or walk backward through PR history checking the UI. This is the whole-app sweep —…

Its SKILL.md is about 3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering UI design, Frontend development and Browser testing. It works with GitHub and Playwright. The repository describes itself as: The open-source IT platform that comes with the workers. RMM + PSA in one system, with a governed AI operator built in. The licence is AGPL-3.0.

When your agent uses it

  • Asks to QA the UI
  • Do extensive UI testing
  • A regression sweep
  • Test everyday flows

Example prompts

  • “QA the UI”
  • “extensive UI testing”
  • “regression sweep”
  • “/ui-qa-sweep”

Requirements

  • Docker

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Environment (read this first, it always bites)
  2. Baseline login + nav crawl
  3. Everyday-workflow checklist
  4. Setup-task checklist (onboarding / configuration)
  5. Backward-through-PRs pass

What it can do on your machine

Read from SKILL.md and the folder at commit 5a2d714. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • docker
    • pnpm
    • curl

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • 2breeze.app

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • E2E_ADMIN_PASSWORD

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

UI QA Sweep loads about 3k tokens when it runs. Until then it costs about 149 tokens; SKILL.md has 1,480 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~149
When it runs · the whole SKILL.md, loaded when a task matches
~3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:67
    Fix: `.env` `PUBLIC_API_URL=http://localhost`, add `http://localhost` to
  • NoteMentions a .env fileSKILL.md:70
    eads env on restart (no image rebuild). `.env` is gitignored — local only.
  • NoteMentions a .env fileSKILL.md:74
    eze.local` / **`BreezeAdmin123!`** (the `.env`

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from LanternOps/breeze at commit 5a2d714, republished under its AGPL-3.0 licence (© LanternOps). 1,480 words, ~2,999 tokens.

Download SKILL.mdSave it as .claude/skills/ui-qa-sweep/SKILL.md (or your agent's skills folder).
name
ui-qa-sweep
description
Broad regression QA of the Breeze RMM web UI via Playwright — exercising everyday MSP workflows and setup tasks like a human QA tester, logging functional PASS/FAIL plus UI/UX observations, and filing GitHub issues from findings. Use this whenever the user asks to "QA the UI", do "extensive UI testing", a "regression sweep", "test everyday flows", "act as QA", verify recently/previously merged PRs end-to-end through the browser, or walk backward through PR history checking the UI. This is the whole-app sweep — for verifying ONE just-built feature use `feature-testing` instead.

UI QA Sweep

Purpose & scope

feature-testing verifies one freshly-implemented feature. This skill is the opposite: a wide regression pass over the whole product as a skeptical human QA tester would do it — log in, click everything an MSP touches day to day, try the setup/onboarding tasks, and walk backward through merged PRs confirming each shipped change still works in the browser. The deliverable is an evidence log (functional results and UI/UX observations) plus GitHub issues for real defects.

Bias toward breadth and skepticism. The most valuable findings here are not "feature X exists" — they're silent failures, dead ends, confusing copy, console errors, broken empty states, and things that look fine but give the user no feedback. Treat "the API returned a clean error but the UI showed nothing" as a bug, not a pass.

Workflow

  1. Environment — get a reachable local stack (this is the usual time sink).
  2. Baseline login + nav crawl — confirm every nav destination renders.
  3. Everyday-workflow checklist — run the recurring-task list below.
  4. Setup-task checklist — run the onboarding/configuration list below.
  5. Backward-through-PRs pass — gh pr list --state merged, newest→oldest, translate each UI-affecting PR into a concrete click-path, verify it.
  6. Log continuously — append to docs/testing/FEATURE_TEST_LOG.md as you go (not just at the end), with a running UI/UX observations sub-log.
  7. File issues — use the github-issues skill; one focused issue per defect, dedupe against open issues first, link to the log.
  8. Tear down — pnpm wt-stack down (or the same--f docker compose ... down -v --remove-orphans for a compose-mode stack) from the worktree that created it, then docker compose ls -a to confirm nothing from this sweep is still up. State in the final summary what you left running and why. Nothing reaps a stack for you — full checklist: worktree-stack skill → "Tear down when done".

Use TaskCreate to track the checklist so progress survives context limits. Prefer dispatching this sweep to a background agent (it is long-running and context-heavy); a single agent must own the Playwright browser — never run two browser-driving agents concurrently against the shared MCP browser.

Phase 1 — Environment (read this first, it always bites)

The local stack is frequently misconfigured for browser access. See the local-playwright-env-setup memory for the full rationale. Short version:

  • Target http://localhost through Caddy :80. Do not use https://2breeze.app (public tunnel is typically down → CF 530; Chromium rejects Caddy's self-signed cert and the MCP browser has no ignoreHTTPSErrors).
  • If login throws "Network error": check PUBLIC_API_URL. The web app preserves the URL scheme, so an https:// value force-upgrades API calls and resets. Fix: .env PUBLIC_API_URL=http://localhost, add http://localhost to CORS_ALLOWED_ORIGINS, leave BREEZE_DOMAIN unset, then docker compose up -d --force-recreate web caddy. Dev web is astro dev and re-reads env on restart (no image rebuild). .env is gitignored — local only.
  • After a --build rebuild, the API container gets a new IP; restart caddy or it 502s the API on a stale upstream.
  • Confirm: curl -s -o /dev/null -w '%{http_code}' http://localhost/health → 200.
  • Login: admin@breeze.local / BreezeAdmin123! (the .env E2E_ADMIN_PASSWORD is stale). Clear login rate limits if needed (see feature-testing Phase 2).

Load Playwright tools via ToolSearch("select:mcp__plugin_playwright_playwright__browser_navigate,...").

Phase 2 — Baseline login + nav crawl

Log in, then visit every sidebar destination once and record: does it render, HTTP status of its primary data call, console errors/warnings. This is cheap and catches the highest-impact regressions (a whole page 500ing). Known noise to note but not chase: a non-platform-admin sees 403 on /admin/account-deletion-requests/pending-count and the third-party catalog (tracked — see issues; don't refile).

Nav surface (current): Dashboard, Devices, Alerts (Alerts/Rules/Channels), Incidents, Remote Access, Scripts, Patches (Compliance/Patches/Update Rings), Fleet, AI Workspace, Network Monitor, Security, Sensitive Data, Peripherals, AI Risk, CIS Benchmarks, Compliance Baselines, Network Discovery, Software Library, Software Policies, Config Policies, Backup, Cloud Backup, Disaster Recovery, Integrations, Reports, Analytics, Audit Trail, Event Logs, Settings (Partner, Organizations, AI Usage, Custom Fields, Saved Filters, Users, Roles, Enrollment Keys).

Phase 3 — Everyday-workflow checklist

These are the things an MSP tech does on a normal day. For each: perform the action through the UI, verify the result is visibly confirmed (toast, state change, list update — not just a 2xx in the network tab), and check no console error. A backend success with no UI feedback is a fail (this is the #1 recurring defect class — see issue #720).

  • Devices: search/filter by status & OS; change page size; open a device; switch device-detail tabs (Overview, Performance, Hardware, Software, Patches, Connections, Event Log); sort columns; bulk-select; tag a device.
  • Device actions: Run Script, Reboot, Wake, Connect Desktop, Remote Tools — each must show success/failure feedback. (Offline fixtures: expect graceful "can't" messaging, not silence.)
  • Alerts: view active alerts; acknowledge / resolve / suppress one; open an alert rule; create + edit + delete a notification channel; click Test on a channel and confirm a visible pass/fail result.
  • Scripts: create a script; import from library; edit; run on a device (script picker shows system scripts); view run output.
  • Patches: view compliance; run a scan; open a device's patch list; approve/reject a patch; filter by source incl. 3rd-party.
  • Remote: open a remote session list; start a session (or graceful offline-device messaging).
  • Search: Cmd+K global search for a device / script / setting; result navigates correctly.
  • Saved filters / tags / custom fields: create one, apply it, delete it.
  • Reports / Analytics / Audit: generate/open a report; audit trail paginates and filters; export buttons respond.
  • Theme / profile: toggle theme; open profile menu; sign out + back in.
Show full SKILL.md (599 more words)Show less

Phase 4 — Setup-task checklist (onboarding / configuration)

These are the things done when setting up a tenant or a new feature. Watch especially for: validation messages being readable (not [object Object], not silent, not over-generic), guided next-steps after creation, and sidebar/list sync after create/delete.

  • Org/site structure: create an organization → guided "add first site" → create a site; rename; delete (named confirm dialog). Verify list + org switcher stay in sync.
  • Users & roles: invite a user; create/edit a role; assign it.
  • Enrollment: create an enrollment key; view the install command; revoke a key.
  • Notification channels: configure each type (Email, Slack, Teams, PagerDuty, Webhook, SMS, Pushover); set partner-level defaults; verify inheritance; create a routing rule.
  • Configuration policies: create a policy; link a feature; assign to an org/site; preview effective config (use the configuration-policy skill for internals).
  • Partner settings: every tab (Company, Regional, Security, Notifications, Defaults, Branding, AI Budgets, Remote-tool providers) — save with valid and invalid input; confirm scheme/URL validation rejects javascript:/data:.
  • Monitoring / Discovery: configure a monitor; start a network discovery scan; view results.
  • Backup / DR: configure a backup SLA; create a DR plan (forms render & validate).
  • Integrations: open the integrations catalog; start a connect flow (OAuth/API-key form renders).

Fixture-limited items (single-org seed, offline devices, no platform admin) — note as BLOCKED with the prerequisite, don't fake a pass. Re-test guidance goes in the log.

Phase 5 — Backward-through-PRs pass

bash
gh pr list --repo LanternOps/breeze --state merged --limit 60 \
  --json number,title,mergedAt --jq 'sort_by(.mergedAt)|reverse|.[]|"\(.number) \(.title)"'

Walk newest→oldest. Skip pure chore/deps/CI/refactor/agent-only PRs (no web surface). For each UI-affecting PR, translate the title into a concrete click-path and verify the change is present and works. When the recent window is covered, keep going further back — this is a backward sweep, there is no natural stopping point except the user's call or running out of UI-affecting PRs. Record the oldest PR number reached so a later run can resume.

Logging format

Append to docs/testing/FEATURE_TEST_LOG.md under a dated ## UI QA Sweep — YYYY-MM-DD section. Write entries as you go, not at the end (a long sweep will hit context limits; unflushed findings are lost).

Per area:

markdown
### [Area / PR#] — PASS | PARTIAL | FAIL | BLOCKED
- ✅ what worked (with the concrete check)
- ❌ BUG: symptom → API actual (status + body) vs UI actual; why it's a bug
- ⚠️ UI/UX: friction, confusing copy, layout, console noise (the parallel log)
- prerequisite/re-test note if BLOCKED

Keep a running UI/UX observations list separate from pass/fail — small papercuts (ambiguous labels, missing empty states, overlays that intercept clicks, console errors, transient toasts) are the point, not a side note.

End with a summary table (area → result) and a "Top findings" section calling out systemic patterns (e.g. "N features share a broken toast path").

Filing issues from findings

Invoke the github-issues skill. Rules that matter here:

  • One focused issue per defect; don't batch unrelated findings.
  • gh issue list --state open and grep for keywords first — dedupe. If related but distinct (different symptom, same file), cross-link, don't refile.
  • Title [UI] symptom...; body = Description (with exact API status+body vs UI behavior), suspected root cause, proposed fix, affected files, "Reported By: internal Playwright UI QA sweep <date>, evidence in FEATURE_TEST_LOG.md".
  • Internal QA ⇒ no @reporter; still don't close issues yourself.

Anti-patterns

  • Declaring PASS on a 2xx without confirming the UI told the user. Silence is a fail.
  • Full-page screenshots/snapshots every step — burns context. Prefer targeted browser_snapshot target=... + browser_evaluate DOM probes; screenshot only when a visual check is the point.
  • Chasing already-tracked noise (the /admin/* 403s) — note once, move on.
  • Faking coverage for fixture-blocked items — mark BLOCKED with the prereq.
  • Doing the whole sweep in the main session — dispatch to a background agent and keep the main context for triage and issue-filing.
  • False silent-failure from selector choice. Many modals/drawers are plain fixed inset-0 divs with no role=dialog. Asserting "did a dialog open" by role/class will wrongly conclude an action silently failed (this bit a Reboot-button check). Assert on the modal's title/body text (or a data-testid) instead, and confirm the outcome (toast/state change), not the container.

© LanternOps, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/ui-qa-sweep of LanternOps/breeze.

Open the folder on GitHubat commit 5a2d714

Compare with similar skills

UI QA Sweep next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

UI QA Sweep compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
UI QA Sweep this skillLanternOps/breeze131—~3kAutomated safety check: NotesAGPL-3.0
Reprovaadin/web-components582—~1.3kAutomated safety check: PassNone
UI Visual DebuggingNangoHQ/nango13k—~1.3kAutomated safety check: PassCustom licence
Verify Debbie Codesdebs-obrien/debbie.codes142—~1.9kAutomated safety check: PassNone
UI Reviewjvm-skills/jvm-skills140—~545Automated safety check: PassApache-2.0
Shogun Screenshotyohey-w/multi-agent-shogun1.4k—~901Automated safety check: NotesMIT

Similar skills

  • Repro

    vaadin/web-components

    Reproduce a Vaadin web component bug from a GitHub issue in vaadin/web-components.

    582 GitHub stars~1.3k tokensUpdated today
    Testing & QAAuto-check passed

  • UI Visual Debugging

    NangoHQ/nango

    A skill your agent uses when modifying or visually debugging Nango frontend UI, including packages/webapp, packages/connect-ui, browser interactions, screenshots, and visual regressions.

    13k GitHub stars~1.3k tokensUpdated today
    Testing & QAAuto-check passed

  • Verify Debbie Codes

    debs-obrien/debbie.codes

    Drive the live debbie.codes Nuxt site (web UI) the way a user does via Playwright — launch the dev server, doctor health, exercise mapped features, capture screenshots/ARIA evidence, and clean up.

    142 GitHub stars~1.9k tokensUpdated 7 days ago
    Testing & QAAuto-check passed

  • UI Review

    jvm-skills/jvm-skills

    Verify UI/UX by running Playwright tests and reviewing screenshots.

    140 GitHub stars~545 tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • Shogun Screenshot

    yohey-w/multi-agent-shogun

    スクリーンショットの取得・加工を行う。ローカルスクショから最新画像を取得、 PlaywrightでWebページをキャプチャ、画像のトリミング・リサイズ、機微情報を黒塗りマスキング。

    1.4k GitHub stars~901 tokensUpdated 2 mo ago
    Testing & QAAuto-check: notes

  • Liteyuki Webui Frontend

    LiteyukiStudio/LiteyukiBot

    Build, review, or test LiteyukiBot v7's React/Vite WebUI under webui/ and its packaged static delivery in packages/webui/.

    157 GitHub stars~2.5k tokensUpdated 1 mo ago
    Frontend & DesignAuto-check passed

More from LanternOps/breeze

All 14 skills in this repo

  • Agent Info

    LanternOps/breeze

    Quick reference for the Breeze RMM Go agent architecture, commands, configuration, build process, and data flows.

    131 GitHub stars~4.7k tokensUpdated today
    Auto-check: notes

  • Agent Log Debugging

    LanternOps/breeze

    A skill your agent uses when debugging agent issues, investigating agent errors, checking agent connectivity, or reviewing agent diagnostic logs.

    131 GitHub stars~1.6k tokensUpdated today
    Auto-check: notes

  • AI Agent

    LanternOps/breeze

    Quick reference for the Breeze RMM AI Agent system architecture, MCP tools, streaming chat, cost tracking, guardrails, and MCP server.

    131 GitHub stars~3.7k tokensUpdated today
    Auto-check passed

  • Breeze Helper

    LanternOps/breeze

    Quick reference for the Breeze Helper Tauri desktop app — architecture, Rust backend commands, React frontend, config files, IPC with the Go agent, helper chat API routes, tool approval flow, and…

    131 GitHub stars~3.2k tokensUpdated today
    Auto-check passed

  • E2E Coverage

    LanternOps/breeze

    A skill your agent uses when running a broad manual/AI-driven end-to-end verification of Breeze RMM across many merged PRs or commits — "test everything since the last release", release-readiness…

    131 GitHub stars~1.6k tokensUpdated today
    Auto-check passed

  • Feature Delivery

    LanternOps/breeze

    A skill your agent uses when orchestrating Breeze implementation work from this seat — dispatching waves or issue fixes to background sessions, deciding whether an open PR gets merged, handling a…

    131 GitHub stars~2.8k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about UI QA Sweep

What does UI QA Sweep do?

Broad regression QA of the Breeze RMM web UI via Playwright — exercising everyday MSP workflows and setup tasks like a human QA tester, logging functional PASS/FAIL plus UI/UX observations, and…. UI QA Sweep is an agent skill from LanternOps/breeze. Broad regression QA of the Breeze RMM web UI via Playwright — exercising everyday MSP workflows and setup tasks like a human QA tester, logging functional PASS/FAIL plus UI/UX observations, and filing GitHub issues from findings.

When should I use UI QA Sweep?

UI QA Sweep fits situations like: asks to QA the UI; do extensive UI testing; A regression sweep; test everyday flows.

How do I install UI QA Sweep in Claude Code?

Run `npx skills add LanternOps/breeze --skill ui-qa-sweep -a claude-code`. Or copy the skill folder (.claude/skills/ui-qa-sweep in LanternOps/breeze) into .claude/skills/ui-qa-sweep in your project. Claude Code loads it when a task matches its description.

How do I install UI QA Sweep in Codex?

Run `npx skills add LanternOps/breeze --skill ui-qa-sweep -a codex`. Or copy the skill folder (.claude/skills/ui-qa-sweep in LanternOps/breeze) into .agents/skills/ui-qa-sweep in your project. Codex loads it when a task matches its description.

Can I use UI QA Sweep in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add LanternOps/breeze --skill ui-qa-sweep -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/ui-qa-sweep, .gemini/skills/ui-qa-sweep, .github/skills/ui-qa-sweep and .opencode/skills/ui-qa-sweep in your project.

What does UI QA Sweep need to run?

Going by SKILL.md and its folder, UI QA Sweep needs the command-line tools its instructions call (gh, docker, pnpm and curl) and credentials named E2E_ADMIN_PASSWORD. Our summary lists: Docker.

Does UI QA Sweep access the network?

SKILL.md names 1 domain. In commands or code: 2breeze.app; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is UI QA Sweep safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does UI QA Sweep use?

UI QA Sweep is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does UI QA Sweep use?

About 3k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to UI QA Sweep?

Skills that share tags, products or a category with UI QA Sweep: Repro (vaadin/web-components, 582 stars), UI Visual Debugging (NangoHQ/nango, 13k stars), Verify Debbie Codes (debs-obrien/debbie.codes, 142 stars) and UI Review (jvm-skills/jvm-skills, 140 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains UI QA Sweep?

LanternOps (a GitHub organization) maintains it in LanternOps/breeze, which has 131 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 8, 2026.

Source: LanternOps/breeze on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.