What does this skill do, and when should you use it?
webapp-testing is a Python Playwright-based skill for interacting with and testing local web applications. It ships a with_server.py helper that manages the lifecycle of one or more dev servers, so the agent only writes plain Playwright automation logic. It prescribes a reconnaissance-then-action workflow — wait for networkidle, screenshot or inspect the DOM, discover selectors, then act — to avoid the common mistake of inspecting the DOM before JavaScript has executed. It works well as the execution layer for agent-driven end-to-end frontend verification.
The skill instructs the model to write native Python Playwright scripts against local web apps. It uses scripts/with_server.py to start and manage servers (multiple --server flags support a backend plus frontend, running the automation script once the ports are ready), then launches headless Chromium, navigates to the page, waits for networkidle, takes screenshots, reads DOM content and discovered elements like buttons, performs clicks/inputs, and captures console logs. The examples/ folder provides three reference scripts: element discovery, static HTML automation via file:// URLs, and console log capture.
- A developer with a local Vite/Next.js dev server who wants an agent to automatically verify that a frontend interaction (button click, form submit) works.
- A full-stack project needing both backend API and frontend running for end-to-end checks, handled in one command via with_server.py's multi-server mode.
- Someone holding a static HTML file who needs to validate structure and interaction selectors — the skill reads the file directly and tests it via a file:// URL.
- Debugging UI rendering or console errors where full-page screenshots and console log capture are needed to diagnose the issue.
How do you install this skill?
- This is a static source review (low confidence); no scripts were executed and runtime behavior is unverified.
- with_server.py runs arbitrary command strings via shell=True, and its output pipes can deadlock on large output; review commands before use.
- Hardcoded paths such as /mnt/user-data/outputs in examples do not exist in most local environments; create the directory or edit paths first.
- Playwright and chromium browser binaries must be installed separately; SKILL.md gives no installation guidance.
- LICENSE.txt referenced by SKILL.md is absent from the reviewed files; treat the repo-level MIT LICENSE as authoritative.
- The skill has no independent version or changelog; diff against upstream when upgrading.
- Shell / CLI
- Network access
- Local filesystem
PythonPlaywright
The skill lives at mini_agent/skills/webapp-testing/ in the Mini-Agent repository (https://github.com/MiniMax-AI/Mini-Agent), bundled with 15 skills. In Development Mode, clone the repo and run git submodule update --init --recursive to initialize skills; in Quick Start Mode, install via uv tool install git+https://github.com/MiniMax-AI/Mini-Agent.git. Place the skill folder where your Claude Code skills are discovered (exact placement is not detailed in the source docs). Playwright must be installed beforehand (pip install playwright && playwright install chromium — this command is not in the source docs; it is standard Playwright setup).
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/MiniMax-AI/Mini-Agent.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/mini_agent/skills/webapp-testing" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- npm run dev
- Run automation against a single dev server:
python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py; for backend + frontend, repeat the --server flag. 2. Write only Playwright logic in your automation script — servers are managed for you, e.g. launch headless Chromium withsync_playwright(),page.goto('http://localhost:5173'),page.wait_for_load_state('networkidle'), then act. 3. Always run any bundled script with--helpfirst; do not read the source unless a custom solution is truly necessary, to avoid polluting your context window. 4. For dynamic apps, inspect (screenshot/DOM) before acting — the reconnaissance-then-action pattern.
What are this skill's strengths and limitations?
- with_server.py automates server lifecycle and supports multiple servers (backend + frontend) in one command.
- Clear decision tree and best practices like 'wait for networkidle before inspecting DOM' reduce common automation failures.
- Helper scripts are designed as black-box invocations, preventing large files from cluttering the agent's context window.
- examples/ offers three directly reusable patterns: element discovery, static HTML, and console logging.
- Requires Python and Playwright (including browser binaries) preinstalled; the skill provides no setup script.
- Docs assume headless Chromium and do not mention support for other browsers.
- The license is stated as 'see LICENSE.txt'; exact terms require checking the repository file.
- SKILL.md includes no dedicated test suite or version information for this skill itself.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Web App Testing Skill this page | 49 · Use with care | ★ 3.1k | 8mo ago | MIT |
| Playwright Browser Automation Skill | 68 · Recommended | ★ 3.2k | 2mo ago | MIT |
| playwright-cli Browser Automation Skill | 56 · Use with care | ★ 11k | 27d ago | MIT |
| Playwright Browser Automation Skill ✓ OpenAI · Official | 52 · Use with care | ★ 28k | 4mo ago | — |
| Playwright Browser Automation ✓ Microsoft · Official | 46 · Use with care | ★ 98k | 11d ago | Apache-2.0 |
How did FollowSkills review this skill?
The skill is local automation: headless Chromium, local port polling, and server cleanup after use; no network exfiltration or credential access; no red-line risk observed. However, with_server.py executes user-supplied commands with shell=True and no confirmation or allowlisting, and SKILL.md does not disclose permission scope, data flow, or rollback — hence the deduction.
with_server.py is self-consistent with clear validation (server/port count matching, timeout errors, finally cleanup); failure messages are diagnosable. But no tests or CI cover this skill; examples hardcode paths like /mnt/user-data/outputs (fail without notice if absent); PIPEd stdout/stderr are never drained, risking deadlock on large output. Static-review cap is 10.
Scenario is clear (local webapp testing) with a decision tree covering static/dynamic pages and single/multiple servers; trigger semantics are reasonably precise. Non-fit boundaries (remote sites, GUI-needed cases) are undeclared, Playwright/browser installation is assumed without instructions, and everything is English-only with no mainland-China considerations — deducted accordingly.
SKILL.md is well-layered (decision tree → examples → reference files) with a license pointer to LICENSE.txt, but that file is absent from the evidence; the skill has no version, changelog, known-limitations section, or FAQ, and maintenance responsibility is only inferable at repo level — hence the deduction.
The core flow (start server → run Playwright script → recon DOM → act) is complete, and with_server.py adds real marginal value (multi-server management, readiness probing, cleanup). But examples use placeholder URLs/paths requiring user adaptation, and nothing was executed; capped at 7 statically, scored 6.
Example and helper scripts are auditable primary material, and claims (e.g., the networkidle pitfall) match the code. However, the repository tests do not cover this skill's key paths, there is no CI evidence or third-party reproduction, so evidence types are thin — scored 4.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →