Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

qa-browser

Étoiles0

Forks0

Mis à jour9 juin 2026 à 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

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

linder3hs

linder3hs/setup-ai

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.