Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

qa-browser

Estrellas0

Forks0

Actualizado9 de junio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

linder3hs

linder3hs/setup-ai

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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.