« /ticket Le bouton Valider déborde sur mobile et la page plante au clic sur iPhone. Plan opus, exécution sonnet, /senior-review en boucle, commit push si tout est ok »
Le skill lit le ticket et le CSS de l'écran, fait écrire un plan, puis un test e2e qui rougit sur iPhone (WebKit, profil d'appareil) avant tout correctif. L'exécutant corrige en TDD, la session relance la gate, vérifie qu'annuler le correctif refait rougir le test et lit les captures aux trois tailles. Quand un tour de /senior-review ne change plus rien, il commite, pousse, et la MR sort du draft.
Ce que ça fait
La session principale orchestre et vérifie, deux agents font le reste. Un agent fort écrit le plan à partir du ticket et du périmètre mesuré dans le code. Un test rouge est écrit avant toute ligne de code, au niveau le plus haut qui attrape le défaut : un scénario e2e dans le harnais du projet quand un écran est touché, avec des captures mobile, tablette et desktop prises par profil d'appareil (tactile, user-agent, WebKit pour l'iPhone) et pas par simple redimensionnement. Un agent standard exécute en TDD. La session relance ensuite elle-même la gate, annule le correctif pour voir le test rougir, relance l'application et lit chaque capture. Enfin, /senior-review tourne en boucle jusqu'au premier tour sans bloquant qui ne modifie plus rien.
Quand l'utiliser
Pour un ticket réel à livrer : bug, petite feature, finding de revue. Un correctif trivial (libellé, garde d'une ligne) prend un chemin court, sans plan ni exécutant. La phrase de lancement fixe les rôles (« plan opus, exécution sonnet, /senior-review en boucle, commit push si tout est ok »), et le commit n'est fait que si elle l'autorise. Pas pour une grosse feature en boucle autonome (feature-loop), ni pour créer seulement l'issue et la branche (issue-mr), ni pour clôturer du travail déjà écrit (branch-wrap-up).
Le parti pris : un ticket est fini quand sa preuve se vérifie du dehors, pas quand « ça a l'air de marcher ». Le rapport sépare trois choses : le code est juste (tests rouges puis verts, mutation inverse), l'effet est visible pour l'utilisateur, et le décor (ce qui a vraiment tourné, ce qui était simulé, ce qui n'a pas été exercé). En fin de ticket, une rétrospective propose au plus trois règles tirées de tes corrections, et rien n'est écrit sans ton accord.
Installer ce skill
$ /plugin marketplace add ohugonnot/claude-skills
$ /plugin install ticket@web-developpeur-skills
Questions fréquentes
Quelle différence avec /feature-loop ?
/feature-loop lance une équipe d'agents qui boucle jusqu'à 8/10 sur chaque axe, et coûte en conséquence : il ne part qu'à la main. /ticket est plus léger, avec un agent pour le plan, un pour l'exécution, et la session principale qui vérifie. C'est le chemin par défaut d'un ticket ordinaire.
Faut-il installer les autres skills ?
Non. /ticket appelle issue-mr, senior-review et branch-wrap-up s'ils sont là, et prévoit un repli sinon (par exemple un relecteur frais en lecture seule par tour à la place de senior-review). Ils sont faits pour aller ensemble, mais aucun n'est obligatoire.
Pourquoi des captures par profil d'appareil plutôt qu'en redimensionnant ?
Un viewport réduit n'a ni le tactile ni le user-agent d'un téléphone, donc une page qui s'adapte à l'appareil se montre dans un état qui n'existe nulle part. Le profil d'appareil reproduit le moteur, et WebKit s'ajoute à Chromium quand l'écran vise l'iPhone. Ce que l'émulation ne montre pas (barre d'adresse iOS, safe-area) est écrit dans la MR comme non vérifié.
Retours & discussion · 0
Aucun retour pour l'instant. Tu l'as essayé ? Dis ce que tu en penses.