Run any Skill in Manus with one click

qa-browser

Stars0

Forks0

UpdatedJune 9, 2026 at 03:20

QA a web app/UI in a real browser — navigate flows, verify state, catch console/network errors, take screenshots as evidence. Use when asked to QA, test the site, verify a deployment, or confirm a UI feature works end-to-end.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

linder3hs

linder3hs/setup-ai

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	qa-browser
description	QA a web app/UI in a real browser — navigate flows, verify state, catch console/network errors, take screenshots as evidence. Use when asked to QA, test the site, verify a deployment, or confirm a UI feature works end-to-end.

Browser QA

Verify the app actually works by driving it, not by reading code.

Steps

Find the URL. Local dev server (start it if needed: npm run dev and read the port) or a deployed/preview URL the user gives.
Pick the driver. Prefer an available browser tool/MCP (Playwright, the browse/gstack skill, or Claude-in-Chrome). Don't pixel-click if a DOM-aware tool exists.
Test the flow. Walk the user-facing path: load → interact (click, fill, submit) → assert the resulting state. Check the critical happy path first, then key edge cases (empty form, invalid input, auth-required route).
Collect evidence. Screenshot before/after key actions. Capture console errors and failed network requests — these are bugs even if the UI looks fine.
Check responsive if relevant: mobile + desktop widths.

Output

Per issue: what you did → what happened → what was expected → screenshot/console evidence. End with a ship/no-ship call. If everything passed, say so with the flows you covered.

More from this repository

same repository

plan-feature

linder3hs/setup-ai

Plan a feature end-to-end before coding — clarify intent, explore existing code for reuse, design the approach, list files to change, and define how to verify. Use before implementing any non-trivial feature or when asked to plan or design work.

2026-06-090

review-diff

linder3hs/setup-ai

Review the current diff/PR for correctness bugs, reuse, simplification, and efficiency. Use before merging, after finishing a change, or when asked to review code.

2026-06-090

scaffold-project

linder3hs/setup-ai

Bootstrap a new project, module, component, or route following existing conventions (or sensible Next.js/React/TS defaults for a fresh repo). Use when asked to scaffold, set up, or create a new component/route/module/project.

2026-06-090

security-audit

linder3hs/setup-ai

Audit code for exploitable security vulnerabilities — injection, auth/authorization flaws, secrets, trust-boundary violations, OWASP Top 10. Use when reviewing security-sensitive code (auth, payments, input handling) or when asked for a security audit. Defensive use only.

2026-06-090

write-tests

linder3hs/setup-ai

Write and run tests that catch real regressions, match the project's existing harness and style, and cover edge/error paths. Use when adding tests, improving coverage, or after implementing a feature.

2026-06-090

name	qa-browser
description	QA a web app/UI in a real browser — navigate flows, verify state, catch console/network errors, take screenshots as evidence. Use when asked to QA, test the site, verify a deployment, or confirm a UI feature works end-to-end.

Browser QA

Verify the app actually works by driving it, not by reading code.

Steps

Find the URL. Local dev server (start it if needed: npm run dev and read the port) or a deployed/preview URL the user gives.
Pick the driver. Prefer an available browser tool/MCP (Playwright, the browse/gstack skill, or Claude-in-Chrome). Don't pixel-click if a DOM-aware tool exists.
Test the flow. Walk the user-facing path: load → interact (click, fill, submit) → assert the resulting state. Check the critical happy path first, then key edge cases (empty form, invalid input, auth-required route).
Collect evidence. Screenshot before/after key actions. Capture console errors and failed network requests — these are bugs even if the UI looks fine.
Check responsive if relevant: mobile + desktop widths.

Output

Per issue: what you did → what happened → what was expected → screenshot/console evidence. End with a ship/no-ship call. If everything passed, say so with the flows you covered.