GUIDE DE TÂCHE · SOURCES ACCESSIBLES

Agent Skills pour tester une application Web

Un plan minimal de skills pour comportement navigateur, journaux, captures et vérifications d’acceptation reproductibles.

Construire ce plan pour mon agent ↗
Résultat souhaité

Prouver qu’un parcours utilisateur critique fonctionne dans un navigateur réel et laisser des preuves reproductibles.

Limites de travail sûres

Utiliser des données de test et un environnement local ou explicitement approuvé.

01 · COMBINAISON DE SKILLS

Une combinaison minimale à trois rôles

Chaque rôle a une seule fonction. Le générateur personnalisé peut adapter la sélection à votre agent sans modifier la logique de décision.

01 · Exécution principale

playwright-workflows

Exerce le parcours utilisateur réel dans un navigateur.

Limite principale
Les fichiers détaillés du paquet ne sont pas intégralement répertoriés.
Premier risque
Revue avant installation
Preuves de source
Source éditoriale
Examiner playwright-workflows ↗
02 · Garde-fou

web-design-guidelines

Définit le périmètre et évite une exécution de tests trop large et sans objectif.

Limite principale
Il dépend de l’accès réseau et d’un document de recommandations en ligne dont le contenu peut évoluer.
Premier risque
Évolution des règles ou constats sans contexte
Preuves de source
Commit figé · 063bee94
Examiner web-design-guidelines ↗
03 · Preuves

Minimal Run and Audit

Conserve les preuves visuelles et d’exécution pour la revue.

Limite principale
Il ne choisit pas la cible de reproduction, n’entraîne pas de modèle, ne réalise pas d’analyse générale de l’article et ne masque pas les changements de sens scientifique.
Premier risque
Modifications scientifiques masquées en corrections de configuration
Preuves de source
Commit figé · fb3ccdf5
Examiner Minimal Run and Audit ↗

02 · MÉTHODE DE TEST WEB

Tester une application Web locale avec le skill webapp-testing

Le skill d’Anthropic vise les applications Web locales et des scripts Playwright Python natifs. Son principe utile est de reconnaître avant d’agir : examiner ce que l’application a réellement rendu avant de choisir des sélecteurs ou d’interagir. C’est un parcours de test fonctionnel délimité, pas un audit de sécurité, une validation de mise en production ou une preuve de couverture multi-navigateurs.

  1. Choisir un parcours critiqueNotez l’état initial, une action utilisateur importante et le résultat visible attendu. Utilisez des données de test isolées et préchargées, sans identifiants de production ni données personnelles.
  2. Ne démarrer que l’application locale prévueSi l’application ne fonctionne pas déjà, lancez d’abord `python scripts/with_server.py --help`. Vérifiez que la commande serveur et le port de l’assistant correspondent au projet et isolez serveur et données de test.
  3. Examiner l’état rendu avant d’agirPour une application dynamique, attendez que la page se stabilise — le guide amont recommande networkidle — puis examinez capture ou DOM. Déduisez les sélecteurs des contrôles réellement présents plutôt que de les deviner.
  4. Vérifier le résultat, pas le clicVérifiez l’URL obtenue, l’état visible ou un enregistrement de test. Un clic sans erreur ne prouve pas que le parcours utilisateur a réussi.
  5. Conserver des preuves limitées et sûresEnregistrez une capture d’échec ou un journal navigateur avec assez de contexte pour reproduire le problème. Fermez le navigateur et ne supprimez que les données de test jetables ; retirez jetons, URL privées et données personnelles avant de partager les journaux.

Exemple illustratif : test rapide de recherche dans un catalogue

Dans un catalogue local contenant deux éléments connus, recherchez un terme, vérifiez que l’élément visé apparaît et que l’autre n’apparaît pas, puis conservez une capture ou un journal si le test échoue. Cela illustre un comportement délimité ; ce n’est ni une mesure de performances ni une certification de l’application.

Lire les instructions actuelles webapp-testing d’Anthropic (vérifiées le 16 octobre 2026) ↗

03 · ACCEPTATION

Comment savoir que la tâche est terminée

  1. Exécuter un parcours critique depuis un état de navigateur propre.
  2. Vérifier l’état de page attendu, pas seulement la réussite d’un clic.
  3. Conserver le signal d’échec nécessaire à la reproduction de tout défaut.

04 · CONDITIONS D’ARRÊT

Quand s’arrêter

  • Le test exige des identifiants de production ou des données personnelles.
  • Le script effectue des actions destructives sans isolation.
  • Un résultat instable est déclaré réussi.

05 · MÉTHODE

Comment ce guide a été produit

SkillSignal associe une tâche définie à trois responsabilités distinctes, puis choisit parmi les métadonnées examinées du catalogue. Adéquation à l’agent, état de source, permissions et scores publiés sont évalués par des règles déterministes. Aucun LLM ne rédige ni ne réordonne la recommandation au moment de la requête.