Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

qa-browser

Sterne0

Forks0

Aktualisiert9. Juni 2026 um 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

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

linder3hs

linder3hs/setup-ai

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

Softwarequalitätssicherungsanalysten und -testerInformatik- und Mathematikberufe·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.

Mehr aus diesem Repository

gleiches 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.