webapp-testing
Skill4 starsChanged 13 days agoMITView on GitHub
Browser automation toolkit using Playwright MCP for testing web applications. Use when asked to navigate pages, click elements, fill forms, take screenshots, verify UI components, check console logs, debug frontend issues, or validate responsive design. Supports live browser interaction and accessibility snapshots.
196 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- rvdbreemen/OTGW-firmwaretheir own version, first seen Nov 8, 2026
- BrightGold70/skillstheir own version, first seen Nov 8, 2026
- DnsQueen/orcinus-skillstheir own version, first seen Nov 8, 2026
- Liang-MH/skillstheir own version, first seen Nov 8, 2026
- smart-coder-labs/nexus-mindtheir own version, first seen Nov 8, 2026
- codewhale-hq/codewhale-plugin-marketplacetheir own version, first seen Nov 8, 2026
Used with
Projects with it also use academy-guide, skill-share and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
AnthropicSkillacademy-guide
Stop and check this skill before finishing any reply to a question about how to use Claude or a Claude product — it recommends matching courses, tutorials, and use cases from Claude Academy (academy.claude.com), Anthropic's learning hub. Trigger on: "how do I", "how can I", "getting started with", "what can Claude do", "teach me", "learn to use"; questions about artifacts, projects, skills, plugins, connectors, MCP; requests about rolling Claude out to a team, class, or organization; and any ask for training materials, onboarding content, or learning resources. Use it when the user is learning how to use a feature or product — not when they are mid-task and just want the task done. This skill composes with other skills: after consulting product documentation to answer how a Claude feature works, also check here for a matching course or tutorial — a docs-grounded answer and an Academy recommendation belong together. Only recommend on a strong match; never invent Academy content.
Also in 8 projects that use this
ArogyaReddySkillskill-share
A skill that creates new Claude skills and automatically shares them on Slack using Rube for seamless team collaboration and skill discovery.
Also in 23 projects that use this
SKB3002Skillintelligent-routing
Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.
Also in 5 projects that use this
ArogyaReddySkillraffle-winner-picker
Picks random winners from lists, spreadsheets, or Google Sheets for giveaways, raffles, and contests. Ensures fair, unbiased selection with transparency.
Also in 26 projects that use this
zephyrwang6Skilltopic-collector
AI热点采集工具。从Twitter/X、Product Hunt、Reddit、Hacker News、博客等采集AI相关热点内容。当用户说"开始今日选题"、"采集热点"、"看看今天有什么新闻"、"今日AI热点"时触发。聚焦领域:Vibe Coding、Claude Skill、AI知识管理、AI模型更新、AI新产品、海外热点。
Also in 4 projects that use this
zephyrwang6Skilldeepl
Übersetzt Texte, Dokumente und XLIFF-Dateien via DeepL API. Verwende für Übersetzungen mit /deepl translate, /deepl file oder /deepl xliff.
Also in 4 projects that use this
- +4 more from zephyrwang6
- +1 more from ArogyaReddy
Other versions196 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- github/awesome-copilot★ 41k46% same
- Typeless-Git/skills★ 146% same
Wrote their own version · 194
- anthropics/skills★ 189ksame name
- ComposioHQ/awesome-claude-skills★ 75ksame name
- ComposioHQ/awesome-codex-skills★ 17ksame name
- composio-community/awesome-codex-skills★ 16ksame name
- vudovn/ag-kit★ 8.2ksame name
- vudovn/antigravity-kit★ 8.2ksame name
- Galaxy-Dawn/claude-scholar★ 5.9ksame name
- microsoft/FluidFramework★ 4.9ksame name
- Prat011/awesome-llm-skills★ 1.7ksame name
- ChenglinPoly/infiAgent★ 1.2ksame name
184 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- grill-me-qaSkill
- playwright-cliSkill
- qa-test-plannerSkill
The file
We split this skill into the rules it gives an agent
11 rules. 1 is common, 10 are distinctive, and 0 are very specific to this project.
1
Common
Most of the 190 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Use this skill when you need to:
- Distinctive: line 15
Create Playwright tests for web applications
- Distinctive: line 16
Test frontend functionality in a real browser
- Distinctive: line 17
Verify UI behavior and interactions
- Distinctive: line 22
Check responsive design across viewports
- Distinctive: line 124
Always verify the app is running: - Check that the local server is accessible before running tests
- Distinctive: line 125
Use explicit waits: - Wait for elements or navigation to complete before interacting
- Common: line 127
Clean up resources: - Always close the browser when done
- Distinctive: line 129
Test incrementally: - Start with simple interactions before complex flows
- Distinctive: line 130
Use selectors wisely: - Prefer data-testid or role-based selectors over CSS classes
- Distinctive: line 190
Check for form fields, buttons, headings in the snapshot
“Common” is measured: kept by at least 6 in 10 of the 190 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Web Application Testing
This skill enables comprehensive browser-based testing and debugging for web applications using Playwright MCP. It provides live browser interaction, UI validation, screenshot capture, console log inspection, and accessibility verification to ensure your web application behaves as expected.
Activation: This skill is triggered when you need to interact with a browser, validate UI elements, capture screenshots, or debug web application issues.
When to Use This Skill
Use this skill when you need to:
- Create Playwright tests for web applications
- Test frontend functionality in a real browser
- Verify UI behavior and interactions
- Debug web application issues
- Capture screenshots for documentation or debugging
- Inspect browser console logs
- Validate form submissions and user flows
- Check responsive design across viewports
Prerequisites
- Node.js installed on the system (v18+)
- A locally running web application (or accessible URL)
- Playwright MCP server configured
- Playwright will be installed automatically if not present
Playwright MCP Tools Reference
Navigation & Interaction
| Tool | Purpose | Example Query |
browser_navigate | Go to a URL | "Navigate to http://localhost:3000/login" |
browser_click | Click elements | "Click the Submit button" |
browser_fill_form | Fill input fields | "Fill the email field with test@example.com" |
browser_hover | Hover over elements | "Hover over the dropdown menu" |
browser_press_key | Keyboard input | "Press Enter" |
browser_select_option | Select from dropdown | "Select 'Option 1' from the dropdown" |
Validation & Capture
| Tool | Purpose | Example Query |
browser_snapshot | Get accessibility tree | "Get the accessibility snapshot" |
browser_take_screenshot | Capture visual state | "Take a screenshot" |
browser_console_messages | View browser logs | "Check for console errors" |
browser_network_requests | Monitor API calls | "Show network requests" |
Browser Management
| Tool | Purpose | Example Query |
browser_resize | Change viewport | "Resize to mobile (375x667)" |
browser_tabs | Manage browser tabs | "List open tabs" |
browser_close | Close browser | "Close the browser" |
Core Capabilities
1. Browser Automation
- Navigate to URLs
- Click buttons and links
- Fill form fields
- Select dropdowns
- Handle dialogs and alerts
2. Verification
- Assert element presence
- Verify text content
- Check element visibility
- Validate URLs
- Test responsive behavior
3. Debugging
- Capture screenshots
- View console logs
- Inspect network requests
- Debug failed tests
Usage Examples
Example 1: Basic Navigation Test
// Navigate to a page and verify heading
await page.goto('http://localhost:3000');
await expect(page.getByRole('heading', { level: 1 })).toBeVisible();Example 2: Form Interaction (Role-Based Locators)
// Fill out and submit a form using accessible locators
await page.getByRole('textbox', { name: 'Username' }).fill('testuser');
await page.getByRole('textbox', { name: 'Password' }).fill('password123');
await page.getByRole('button', { name: 'Login' }).click();
await expect(page).toHaveURL(/.*dashboard/);Example 3: Screenshot Capture
// Capture a full-page screenshot for debugging
await page.screenshot({ path: 'debug.png', fullPage: true });Example 4: Accessibility Snapshot Assertion
// Verify page structure with aria snapshot
await expect(page.getByRole('main')).toMatchAriaSnapshot(`
- main:
- heading "Welcome" [level=1]
- form:
- textbox "Email"
- textbox "Password"
- button "Login"
`);Guidelines
- Always verify the app is running - Check that the local server is accessible before running tests
- Use explicit waits - Wait for elements or navigation to complete before interacting
- Capture screenshots on failure - Take screenshots to help debug issues
- Clean up resources - Always close the browser when done
- Handle timeouts gracefully - Set reasonable timeouts for slow operations
- Test incrementally - Start with simple interactions before complex flows
- Use selectors wisely - Prefer data-testid or role-based selectors over CSS classes
Common Patterns
Pattern: Wait for Element (Role-Based)
await page.getByRole('button', { name: 'Submit' }).waitFor({ state: 'visible' });Pattern: Check if Element Exists
const exists = await page.getByRole('alert').count() > 0;Pattern: Capture Console Logs
page.on('console', msg => console.log(`[${msg.type()}] ${msg.text()}`));Pattern: Handle Errors with Screenshot
try {
await page.getByRole('button', { name: 'Submit' }).click();
} catch (error) {
await page.screenshot({ path: 'error.png' });
throw error;
}Pattern: Test Responsive Viewports
const viewports = [
{ width: 375, height: 667, name: 'mobile' },
{ width: 768, height: 1024, name: 'tablet' },
{ width: 1920, height: 1080, name: 'desktop' },
];
for (const vp of viewports) {
await page.setViewportSize({ width: vp.width, height: vp.height });
await page.screenshot({ path: `${vp.name}.png` });
}Step-by-Step Workflows
Workflow 1: Validate a Page with Playwright MCP
- Navigate to the page
"Navigate to http://localhost:3000/login" - Get accessibility snapshot
"Get the accessibility snapshot" - Verify expected elements exist
- Check for form fields, buttons, headings in the snapshot
- Take a screenshot for documentation
"Take a screenshot" - Check for console errors
"Show console messages"
Workflow 2: Debug a Failing Test
- Navigate to the problematic page
"Navigate to http://localhost:3000/checkout" - Capture initial state
"Take a screenshot" - Get accessibility snapshot to understand structure
"Get the accessibility snapshot" - Identify the correct locator from the snapshot
- Test the interaction
"Click the 'Add to Cart' button" - Verify result and capture evidence
"Take a screenshot" "Check for console errors"
Workflow 3: Test Responsive Design
- Navigate to the page
"Navigate to http://localhost:3000" - Test mobile viewport
"Resize browser to 375x667" "Take a screenshot" "Verify hamburger menu is visible" - Test tablet viewport
"Resize browser to 768x1024" "Take a screenshot" - Test desktop viewport
"Resize browser to 1920x1080" "Verify navigation links are visible"
Troubleshooting
| Problem | Cause | Solution |
| Element not found | Wrong locator or element not rendered | Use browser_snapshot to verify structure |
| Timeout waiting for element | Element hidden or slow to load | Check for overlays, increase timeout |
| Strict mode violation | Multiple elements match locator | Add more specific filters like { exact: true } |
| Click intercepted | Another element covering target | Scroll into view or wait for overlay to close |
| Console errors in app | JavaScript runtime errors | Use browser_console_messages to debug |
| Screenshot blank | Page not fully loaded | Wait for network idle or specific element |
| Form submission fails | Validation errors not visible | Check for error messages in snapshot |
Locator Strategy (Priority Order)
// ✅ BEST: Role-based (accessible, resilient)
page.getByRole('button', { name: 'Submit' })
page.getByRole('textbox', { name: 'Email' })
page.getByRole('link', { name: 'Sign up' })
// ✅ GOOD: User-facing text
page.getByLabel('Email address')
page.getByPlaceholder('Enter your email')
page.getByText('Welcome back')
// ✅ GOOD: Test IDs (stable, explicit)
page.getByTestId('submit-button')
// ⚠️ AVOID: CSS selectors (brittle)
page.locator('.btn-primary')
// ❌ NEVER: XPath (extremely brittle)
page.locator('//div[@class="container"]/button[1]')Limitations
- Requires Node.js environment (v18+)
- Cannot test native mobile apps (use Appium or Detox instead)
- Complex authentication flows may require session storage or API login
- Some modern frameworks with shadow DOM require specific configuration
- Heavy animations may require disabling for stable tests
References
- Locator Strategies Guide - Detailed locator patterns and best practices
- Common Test Patterns - Reusable test patterns and utilities
- Page Object Model Guide - POM implementation and best practices
- API Testing Guide - API testing, mocking, and request interception
- Test Helper Utilities - JavaScript helper functions
Quick Commands
| Task | Playwright MCP Query |
| Open page | "Navigate to {URL}" |
| Check structure | "Get the accessibility snapshot" |
| Capture evidence | "Take a screenshot" |
| Fill form | "Fill the {field} with {value}" |
| Click element | "Click the {name} button" |
| Check errors | "Show console messages" |
| Test mobile | "Resize browser to 375x667" |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

