qa-only

Aperçu du skill qa-only

qa-only est un skill de QA en mode rapport uniquement, conçu pour les cas où vous voulez qu’une application web soit testée, que les bugs soient documentés et que des preuves soient recueillies, sans qu’aucune correction ne soit apportée. Le skill qa-only convient particulièrement aux reviewers QA, aux product owners et aux agents qui ont besoin d’un flux de travail propre de remontée de bugs plutôt que d’une boucle test-correction-vérification. Si votre objectif est « trouver les problèmes et les rédiger », qa-only est le bon choix ; si vous voulez des modifications de code, utilisez plutôt /qa.

À quoi sert qa-only

Ce skill se concentre sur des livrables QA structurés : score de santé, captures d’écran, étapes de reproduction et rapport de bug clair. Il est pensé pour les demandes du type « vérifie seulement s’il y a des bugs » et « teste, mais ne corrige pas », afin de réduire l’ambiguïté quand l’utilisateur veut des preuves, pas une implémentation.

Pourquoi qa-only est différent

La principale valeur du qa-only skill tient à sa retenue. Il oriente l’agent vers un comportement de reporting et évite les corrections accidentelles, ce qui est important lorsque le livrable attendu est un artefact de revue, une note de triage ou un rapport de passation. C’est ce qui rend qa-only for Qa particulièrement utile dans les contextes où les actions de correction sont hors périmètre ou risquées.

Pertinence et cas où il ne convient pas

Utilisez qa-only quand vous avez besoin d’un passage QA sur une application existante, surtout pour découvrir des bugs, repérer des régressions ou produire une évaluation écrite. Ne l’installez pas comme assistant de test général si vous avez besoin de modifications de code, de refactoring ou de correction itérative de bugs ; le qa-only guide est volontairement centré sur le rapport, pas sur la réparation.

Comment utiliser le skill qa-only

Installer et vérifier le skill

Utilisez le flux d’installation basé sur le dépôt : npx skills add garrytan/gstack --skill qa-only. Après l’installation, vérifiez que les fichiers du skill sont bien présents et lisibles dans votre répertoire de skills avant de vous en servir en production. Le qa-only install n’est utile que si votre agent peut réellement charger le contexte du skill pendant les sessions de QA.

Donner le bon prompt de départ

Un bon prompt qa-only usage doit préciser l’application, la cible du test, ce que signifie « rapport de bug uniquement » et les limites. De bons exemples ressemblent à : « Lance qa-only sur le parcours de paiement en staging, ne remonte que les bugs visibles, inclue les étapes de reproduction et les notes de capture d’écran, ne propose aucune correction. » Des formulations faibles comme « fais la QA de cette application » laissent trop de place au modèle pour deviner le périmètre et la gravité.

Lire ces fichiers en premier

Commencez par SKILL.md, puis examinez SKILL.md.tmpl pour comprendre comment le workflow généré est assemblé. Comme ce repo n’inclut ni rules/, ni resources/, ni scripts supplémentaires, les deux fichiers du skill sont la véritable source de vérité pour le comportement, les déclencheurs et les contraintes. C’est le chemin le plus rapide si vous voulez comprendre qa-only avant de l’adopter.

L’utiliser dans un workflow QA concret

Un bon qa-only guide suit ce schéma : définissez la zone à tester, capturez le comportement attendu, laissez le skill mener une revue ciblée, puis transformez le résultat en liste de bugs ou en mémo QA. Si le premier résultat est trop large, resserrez le périmètre sur un seul parcours utilisateur, un seul appareil/navigateur ou une seule release candidate. Le skill est le plus efficace quand la tâche est bien bornée et que le format du rapport est explicite.

FAQ du skill qa-only

qa-only est-il réservé aux applications web ?

Dans la majorité des cas, oui. qa-only est destiné à la QA d’applications web et au reporting de bugs, donc il convient aux parcours UI, aux environnements de staging et aux trajets utilisateur observables et documentables. Il est moins utile pour une validation côté backend ou pour des tâches où il n’existe aucun comportement produit visible.

En quoi est-il différent d’un prompt normal ?

Un prompt classique peut demander de faire de la QA, mais le qa-only skill ajoute une posture de reporting cohérente et des règles plus claires autour du « ne pas corriger ». Cela réduit les allers-retours quand l’équipe a besoin d’un rapport d’incident propre plutôt que d’un résultat mêlant analyse et implémentation.

qa-only est-il adapté aux débutants ?

Oui, si l’utilisateur sait nommer l’application, l’environnement et l’objectif. L’erreur la plus fréquente chez les débutants est de trop peu préciser le périmètre ; le qa-only guide fonctionne mieux quand vous dites quoi tester, quelles preuves collecter et ce qu’il ne faut pas faire. Sans cela, le rapport risque d’être trop générique pour être exploitable.

Quand ne faut-il pas utiliser qa-only ?

N’utilisez pas qa-only si votre besoin réel est du debug, un correctif ou la vérification de bout en bout d’une correction. C’est aussi un mauvais choix si vous avez besoin d’une mise en place poussée d’automatisation des tests, de travail sur l’infrastructure ou de tout ce qui dépend d’un accès en écriture pour modifier le code.

Comment améliorer le skill qa-only

Définir un périmètre plus serré et des signaux d’acceptation plus forts

La meilleure façon d’améliorer la sortie de qa-only est de définir une cible unique et une condition de succès claire. Par exemple : « Teste le formulaire de connexion sur mobile Safari, signale les validations cassées, inclue les étapes, le comportement attendu vs observé et les références de capture d’écran. » Cela donne au skill un cadre mesurable au lieu d’une demande d’audit vague.

Ajouter les preuves que le rapport doit contenir

Si vous voulez un rapport qa-only plus utile, demandez des artefacts précis : étapes de reproduction, URL ou route affectée, gravité, fréquence, et indication de blocage, d’impact visuel ou de caractère intermittent. C’est préférable à « trouve des bugs », car cela force des constats structurés qu’une autre personne pourra exploiter rapidement.

Surveiller les modes d’échec fréquents

Le mode d’échec le plus courant est une couverture trop large : l’agent essaie de tout tester et le rapport devient superficiel. Un autre écueil consiste à mélanger une intention de correction avec une tâche en mode rapport uniquement, ce qui affaiblit l’objectif de qa-only. Si cela arrive, reformulez clairement : « rapport uniquement, aucune correction, aucun changement de code », puis resserrez la surface de test.

Passer d’un premier rapport à un second passage

Utilisez un premier passage pour repérer les problèmes probables, puis lancez un second passage qa-only sur les parcours de bug les plus importants. C’est particulièrement utile quand le premier rapport révèle un flux critique, mais que vous voulez confirmer plus précisément les cas limites, les différences entre navigateurs ou la fiabilité de reproduction. C’est dans l’itération que qa-only devient une habitude QA fiable plutôt qu’un simple prompt ponctuel.