To test local web applications, write native Python Playwright scripts.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionwebapp-testingExecute the skills CLI command in your project's root directory to begin installation:
Fetches webapp-testing from davila7/claude-code-templates and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate webapp-testing. Access via /webapp-testing in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
24.2K
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
24.2K
stars
To test local web applications, write native Python Playwright scripts.
Helper Scripts Available:
scripts/with_server.py - Manages server lifecycle (supports multiple servers)Always run scripts with --help first to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.
User task → Is it static HTML?
├─ Yes → Read HTML file directly to identify selectors
│ ├─ Success → Write Playwright script using selectors
│ └─ Fails/Incomplete → Treat as dynamic (below)
│
└─ No (dynamic webapp) → Is the server already running?
├─ No → Run: python scripts/with_server.py --help
│ Then use the helper + write simplified Playwright script
│
└─ Yes → Reconnaissance-then-action:
1. Navigate and wait for networkidle
2. Take screenshot or inspect DOM
3. Identify selectors from rendered state
4. Execute actions with discovered selectors
To start a server, run --help first, then use the helper:
Single server:
python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py
Multiple servers (e.g., backend + frontend):
python scripts/with_server.py \
--server "cd backend && python server.py" --port 3000 \
--server "cd frontend && npm run dev" --port 5173 \
-- python your_automation.py
To create an automation script, include only Playwright logic (servers are managed automatically):
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
page = browser.new_page()
page.goto('http://localhost:5173') # Server already running and ready
page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
# ... your automation logic
browser.close()
Inspect rendered DOM:
page.screenshot(path='/tmp/inspect.png', full_page=True)
content = page.content()
page.locator('button').all()
Identify selectors from inspection results
Execute actions using discovered selectors
❌ Don't inspect the DOM before waiting for networkidle on dynamic apps
✅ Do wait for page.wait_for_load_state('networkidle') before inspection
scripts/ can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use --help to see usage, then invoke directly.sync_playwright() for synchronous scriptstext=, role=, CSS selectors, or IDspage.wait_for_selector() or page.wait_for_timeout()element_discovery.py - Discovering buttons, links, and inputs on a pagestatic_html_automation.py - Using file:// URLs for local HTMLconsole_logging.py - Capturing console logs during automationPrerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
davila7/claude-code-templates
davila7/claude-code-templates
davila7/claude-code-templates
davila7/claude-code-templates
davila7/claude-code-templates
davila7/claude-code-templates
webapp-testing has been reliable in day-to-day use. Documentation quality is above average for community skills.
Keeps context tight: webapp-testing is the kind of skill you can hand to a new teammate without a long onboarding doc.
Registry listing for webapp-testing matched our evaluation — installs cleanly and behaves as described in the markdown.
I recommend webapp-testing for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
webapp-testing fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
webapp-testing reduced setup friction for our internal harness; good balance of opinion and flexibility.
Registry listing for webapp-testing matched our evaluation — installs cleanly and behaves as described in the markdown.
Solid pick for teams standardizing on skills: webapp-testing is focused, and the summary matches what you get after install.
Keeps context tight: webapp-testing is the kind of skill you can hand to a new teammate without a long onboarding doc.
Useful defaults in webapp-testing — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
showing 1-10 of 72