QA

Pilotez un site web avec un vrai navigateur, jugez la qualité de sa performance pour ce que l'utilisateur a demandé, et retournez un score de 1 (cassé) à 5 (excellent) avec des preuves. Le livrabe est un verdict, pas un dump de captures d'écran.

Entrées

À partir de l'invocation de l'utilisateur (le texte après /qa, ou son message) :

• Cible — une URL (https://…) ou un serveur de développement local (localhost:5173, :3000, « l'app sur 5173 »). Obligatoire — si absent, demandez-la avant tout.
• Quoi tester (optionnel) — un flux ou un focus (« l'inscription », « recherche + filtres »). Si omis, testez le chemin heureux le plus évident et mentionnez-le dans le rapport.

Peux-tu voir les images ? (décide d'abord)

Le verdict de cette skill est visuel — tu juges l'app en regardant des captures d'écran. Avant toute chose, vérifie si toi — l'agent qui exécute cette skill — peux réellement voir les images :

• Tu as la vision (multimodal / entrée image) → tu peux juger les captures d'écran toi-même. Continue vers « Single flow vs. fan-out » ci-dessous et choisis selon l'ampleur.
• Tu n'as pas la vision (modèle text-only, pas de support image) → tu ne peux pas juger les captures d'écran, et non plus les subagents du même modèle que tu spawnerais. Tu dois déléguer le jugement visuel aux agents cloud Browser Use v2, dont le propre LLM observe la page côté serveur et retourne un verdict textuel (judge pass/fail + un structuredOutput 1–5). Utilise v2 pour chaque flux — même un seul — par references/browser-use-v2.md. Ne pilote pas browser-harness toi-même pour lire les captures d'écran, et ne fan-out pas vers tes propres subagents (tout aussi aveugles). Le choix single-flow-vs-fan-out ci-dessous ne t'apply pas — c'est v2 de toute façon.

Si tu es incertain de pouvoir voir les images, suppose que non et utilise v2.

Single flow vs. fan-out (seulement si tu peux voir les images)

Adapte l'approche à la demande :

• Tester un seul flux / une seule chose ? Ne t'embête pas avec les subagents — pilote browser-harness directement toi-même, en suivant references/methodology.md. C'est le bon outil, le moins lourd, pour un seul test, et c'est comme le reste de cette skill fonctionne.
• Tester beaucoup de flux / beaucoup de choses à la fois ? Fan-out vers des subagents — un par flux — pour qu'ils tournent en parallèle. Ici l'utilisateur a le choix du type de subagent (demande si flou ; recommande v2) :
  • Agents cloud Browser Use v2 — recommandé. Chaque flux devient une tâche v2 autonome avec judge (pass/fail) + structuredOutput (score 1–5), tournant côté serveur et en parallèle, retournant des preuves screenshot étape par étape. Consomme des crédits Browser Use (~$0,01/tâche + ~$0,006/étape + $0,02/h navigateur). Flux par tâche + comment fan-out : references/browser-use-v2.md.
  • Subagents intégrés de ton harness — spawne des subagents Claude Code (l'outil Agent), chacun pilotant browser-harness via references/methodology.md. Pas de crédits de tâche Browser Use ; utilise ta propre consommation d'agent.

Règle d'or (agents vision uniquement — les agents text-only utilisent v2 pour tout, voir ci-dessus) : un flux → browser-harness directement ; beaucoup de flux → subagents (v2 recommandé). De toute façon browser-harness est obligatoire — comme pilote direct, pilote de subagent, clé-dépôt v2, et tunnel localhost.

Dépendance : browser-harness (obligatoire — installe-le toi-même)

Cette skill exécute le test via browser-harness — un outil séparé que tu installes une fois. Ce n'est pas optionnel ; QA doit tourner sur un vrai navigateur Browser Use cloud, jamais le Chrome local de l'utilisateur.

Avant toute chose, vérifie qu'il est disponible :

command -v browser-harness && browser-harness <<'PY'
print("browser-harness OK")
PY

Si browser-harness n'est pas sur PATH, installe-le toi-même — ne le fais pas faire à l'utilisateur. QA tourne sur un navigateur cloud, donc le CLI suffit : aucun de la config du navigateur local de browser-harness (chrome://inspect, --remote-debugging-port, la popup « Allow remote debugging ») ne s'apply ici — saute tout. L'installation est une fois (~30s), pas de clone :

command -v uv || curl -LsSf https://astral.sh/uv/install.sh | sh   # l'installeur uv, seulement s'il manque
uv tool install "git+https://github.com/browser-use/browser-harness"
command -v browser-harness                                         # vérifie qu'il est sur PATH maintenant

(Pas de uv et pas de curl | sh possible ? Installe uv par https://docs.astral.sh/uv/getting-started/installation/ puis re-lance la ligne uv tool install — ou pipx install "git+https://github.com/browser-use/browser-harness".)

La seule autre chose qu'une exécution nécessite est une BROWSER_USE_API_KEY, et celle-ci aussi se résout auto sans humain — voir references/methodology.md étape 0 (elle peut auto-s'enregistrer pour une clé gratuite). Une machine fraîche passe donc de « vient d'installer qa » à un test fonctionnel sans que l'utilisateur fasse aucune config.

En dernier recours seulement — si tu vraiment ne peux pas l'installer (pas de réseau, pas de Python) : arrête et fais ouvrir à l'utilisateur https://www.browser-harness.com/ et colle le « prompt for LLMs » dans un agent :

Set up https://github.com/browser-use/browser-harness for me. Read install.md first to install and connect this repo to my real browser. Then read SKILL.md for normal usage. Always read helpers.py because that is where the functions are. When you open a setup or verification tab, activate it so I can see the active browser tab. After it is installed, open this repository in my browser and, if I am logged in to GitHub, ask me whether you should star it for me as a quick demo that the interaction works — only click the star if I say yes. If I am not logged in, just go to browser-use.com.

Re-lance command -v browser-harness et ne continue pas jusqu'à ce que ça réussisse. Ne reviens jamais à un fallback sur le Chrome local de l'utilisateur.

N'essaie pas de faire QA avec n'importe quoi d'autre que browser-harness + un navigateur cloud.

Procédure

1. Confirme que la cible est accessible (curl -s -o /dev/null -w "%{http_code}" <url>), et identifie ce que l'app est (titre, README) pour que tu puisses cadrer une tâche de test sensée.

2. Exécute-la — applique d'abord le filtre vision de « Peux-tu voir les images ? » ci-dessus :

   • Pas de vision (text-only) ? → utilise des agents v2 cloud pour chaque flux (une tâche v2 par flux, chacune avec judge + un structuredOutput 1–5), par references/browser-use-v2.md. Saute le split single-flow/subagent ci-dessous — c'est v2 peu importe l'ampleur. Tunnelise une cible localhost et passe la startUrl publique.
   • Vision, un seul flux → pilote browser-harness directement par references/methodology.md : résous la clé, tunnelise localhost, et exécute la boucle de test avec les pièges éprouvés (réécriture host-header, sans proxy, en-tête interstitiel par onglet, APIs pinned CORS).
   • Vision, beaucoup de flux → fan-out, un subagent par flux :
     • Agents v2 (recommandé) → par references/browser-use-v2.md, crée une tâche par flux (chacune avec judge + schéma structuredOutput 1–5), poll tous, et collecte les verdicts. Une cible localhost a encore besoin d'un tunnel (l'agent cloud ne peut pas atteindre localhost) — tunnelise-la et passe la startUrl publique.
     • Subagents Claude → spawne un Agent par flux, chacun suivant references/methodology.md sur browser-harness.

   Quand tu utilises le backend v2 (soit le cas sans vision soit le fan-out recommandé) : à chaque création de tâche, ouvre le fil dashboard https://cloud.browser-use.com/thread/{sessionId} (l'id de session de la réponse create — pas l'id de tâche) dans le Chrome local de l'utilisateur pour qu'il puisse regarder l'agent tourner — le helper open_local(...) de la référence fait ça. Imprime toujours l'URL aussi.

3. Fais le nettoyage de ce que tu as démarré — arrête tout ce que tu as ouvert, sur tous les chemins :

   • Tunnel — si tu as tunnelisé une cible localhost, tue le processus tunnel. Ceci s'apply à chaque chemin qui tunnelise, v2 inclus (une exécution v2 contre localhost démarre quand même un tunnel) — ne le laisse pas orphelin.
   • Navigateur cloud — les chemins one-flow / Claude pilotent un navigateur cloud browser-harness ; arrête-le.
   • Une tâche v2 contre une URL publique n'a rien à nettoyer (sa session one-off se ferme auto) ; une tâche v2 contre localhost laisse quand même le tunnel, donc ferme-le.

4. Retourne le verdict : ouvre avec Score: N/5, puis tâche, résultat, ce qui a marché, problèmes (étiquetés), cas limites, et preuve — par la rubrique et le format de sortie dans references/methodology.md. Fan-out ? Donne une ligne Score: N/5 par flux et un score global qui reflète le chemin critique le plus faible (ne fais pas la moyenne en remontant un flux cassé parce que d'autres ont réussi).

Adapte l'effort à la demande : un rapide « ça marche X ? » c'est quelques interactions et un score ; « QA complet de ça » mérite plus de flux et cas limites. Garde le verdict honnête, spécifique, et reproductible.