prototype (mattpocock/skills)

Avis

Codex CLI 0.166 (gpt-6-astra, low reasoning) sur un Mac de test, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (traitement) ou absent (contrôle) ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « prompt d'une phrase »), 2 exécutions par groupe et par tâche, réseau coupé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée ci-dessous). Trois tâches : modéliser un cycle de vie d'abonnement avec des échecs de paiement (question d'état), comparer des options pour une section de tarifs statique (question d'apparence, le vrai contenu des offres doit rester), et permettre à l'utilisateur d'essayer les règles d'empilement de remises avant de coder (question de logique, enregistrer dans prototype/). Les contrôles incluent un HTML autonome, cinq états affichés, des boutons par événement, des scénarios guidés, la mention prototype, aucun fichier de test, et pour la tâche de tarifs au moins trois variantes, un paramètre d'URL ?variant= et un sélecteur flottant fixe.

Comparaison à trois bras

Mesuré avec Codex CLI sur 18 exécutions, noté par des contrôles basés sur des règles, sans juge LLM. Total 27.2 / 30, verdict Recommandé.

Verdict : recommandé (27.2 / 30). Source : mattpocock/skills, skills/engineering/prototype, épinglé au commit 4ae2317. Installation : npx skills@latest add mattpocock/skills --skill prototype. Licence : MIT (LICENSE du dépôt).

Présentation

Le skill prototype de mattpocock/skills : il construit un prototype jetable qui répond à une question de design. Les questions de logique ou d'état reçoivent un seul fichier HTML avec un panneau d'état, des boutons de manipulation libre et des parcours guidés ; les questions d'apparence reçoivent plusieurs variantes radicalement différentes sur une même route, commutées par un paramètre d'URL et une barre flottante en bas. Règles : clairement marqué comme jetable, trivial à lancer, aucune persistance, aucun soin esthétique, aucun test. SKILL.md plus LOGIC.md et UI.md, environ 2 600 mots au total ; Markdown uniquement.

Notre méthode de test

Codex CLI 0.166 (gpt-6-astra, raisonnement faible) sur une machine de test Mac, un projet temporaire neuf et des HOME/TMPDIR/caches temporaires à chaque exécution, skill installé (groupe traité) ou absent (groupe témoin), ou absent avec l'exigence centrale du skill compressée en une phrase ajoutée au prompt (groupe « une phrase »), 2 exécutions par groupe et par tâche, réseau coupé, écritures dans /tmp bloquées. Les prompts ne mentionnent jamais le skill (sauf la formulation indiquée ci-dessous).

Trois tâches : modéliser un cycle de vie d'abonnement avec des échecs de paiement (question d'état), comparer des options pour une section tarifaire statique (question d'apparence, le contenu réel des offres doit rester), et permettre à l'utilisateur d'essayer des règles d'empilement de remises avant de coder (question de logique, enregistrement dans prototype/). Les vérifications de règles portent sur : HTML autonome, cinq états affichés, un bouton par événement, des scénarios guidés, un marquage comme prototype, aucun fichier de test, et pour la tâche tarifaire au moins trois variantes, un paramètre d'URL ?variant= et un sélecteur flottant fixe.

1. Prototyper un modèle d'état d'abonnement — Je n'arrive pas à savoir si notre cycle de vie d'abonnement tient la route quand des paiements échouent. États : trial, active, past_due, paused, canceled. Événements : fin de l'essai, paiement réussi, paiement échoué, mise en pause par l'utilisateur, reprise par l'utilisateur, annulation par l'utilisateur, réactivation par l'utilisateur. Règles : deux échecs…
2. Prototyper des variantes de page tarifaire — Sur pricing.html de ce petit site statique (trois offres), je ne sais pas comment présenter les offres. Fais quelques options de design différentes de cette section que je peux comparer dans le navigateur ; le contenu tarifaire réel doit rester. Pas d'étape de build.
3. Prototyper des règles d'empilement de remises — L'empilement des remises vous semble-t-il juste ? Règles actuelles : le coupon SAVE10 donne 10% de réduction, le coupon HALF 50%, les commandes de plus de $50 sont livrées gratuitement, les membres du programme de fidélité ont 5% de plus. Je n'arrive pas à décider dans quel ordre elles s'appliquent ni lesquelles peuvent s'empiler. Je veux essayer des cas et voir ce qui…

Le scoring est programmatique (tests cachés / rappel des anomalies introduites / vérifications de contraintes / rendu + OCR le cas échéant), 0–5 par exécution. Aucun juge LLM n'a décidé d'un seul score.

Résultats

Le prompt d'une phrase donné au troisième groupe : « Construis un prototype jetable qui répond à une question énoncée : pour les questions de logique ou d'état, un seul fichier HTML autonome avec un énoncé visible de la question, un panneau d'état courant lisible, re-rendu après chaque clic, un bouton par action, et des scénarios de parcours guidés (chemin nominal, cas limite, coup illégal) ; pour les questions d'apparence, trois variantes radicalement différentes sur une même page, commutées par un paramètre d'URL ?variant= et une barre flottante en bas. Aucun test, aucun soin esthétique. »

Score moyen : 3.71 sans contre 4.95 avec le skill (delta +1.23). Tokens par exécution : 133k contre 136k (1.02x) ; temps 186s contre 149s. Groupe « une phrase » : 4.72 (gain du skill sur le prompt d'une phrase : +0.23 ; gain du prompt d'une phrase sur l'absence de skill : +1.01) ; 89k tokens par exécution pour le prompt d'une phrase, donc le skill coûte 1.52x ce prompt.

Ce qui s'est passé

• Score moyen de 3.71 pour le témoin, 4.72 pour la version en une phrase, 4.95 pour le skill. Le skill apporte +1.24 par rapport au témoin et +0.23 par rapport au prompt d'une phrase, à 136k tokens par exécution contre 133k (1.02x) pour le témoin et 89k pour le prompt d'une phrase (1.5x).
• La tâche d'apparence montre l'effet : le skill a produit trois variantes avec un sélecteur flottant en bas et des variantes commutables par URL dans les deux exécutions (5.0 et 5.0 selon nos vérifications) ; le témoin a obtenu 4.0 et 1.0 : aucune barre flottante dans l'une ou l'autre exécution, trois mises en page avec un sélecteur et un paramètre d'URL dans une exécution mais pas dans l'autre, et dans une exécution le prix d'une offre manquait sur la page.
• Sur les deux tâches de logique, le témoin construisait déjà du HTML interactif (4.4-4.8 sur le modèle d'abonnement, 4.0 sur l'empilement de remises) ; le skill ajoute les scénarios guidés et le label prototype : les scénarios apparaissent dans 4 exécutions sur 4 avec le skill contre 2 sur 4 pour le témoin.
• La version en une phrase a fait aussi bien sur la tâche tarifaire ; elle a perdu un peu sur les tâches de logique en ne marquant pas toujours le fichier comme prototype (2 exécutions sur 4).

Scores par dimension

Limites de ce test

• Vérifications basées sur des règles portant sur des fonctionnalités (variantes, barre flottante, scénarios) ; la qualité des designs et le fait que le prototype réponde à la question n'ont pas été jugés par une personne.
• Le scoring a été corrigé deux fois pendant l'analyse : les variantes peuvent vivre dans des fichiers CSS/JS séparés, et un sélecteur de mise en page compte comme une variante ; la première passe les sous-comptait, donc les chiffres antérieurs ne sont pas utilisés.
• Le conseil du skill de committer le prototype sur une branche jetable et de laisser un pointeur dans une issue ne peut pas être testé dans un dossier de travail temporaire.
• n = 2 par groupe et par tâche : les différences inférieures à environ 1 point relèvent du bruit.
• Le scoring basé sur des règles mesure ce que les vérifications peuvent voir ; il ne peut juger du goût ni du caractère optimal d'un résultat.

Sécurité

Voir security.md. Scan : 1 CRITICAL / 1 HIGH / 0 MEDIUM. Verdict : sûr à exécuter (sandbox sans réseau). Un scan propre ne prouve pas qu'un skill est sûr.

En résumé

Le skill amène clairement Codex à construire le type de prototype qu'il décrit (variantes commutables par URL, barre flottante, scénarios guidés) là où une simple demande ne le fait pas, sans surcoût en tokens. Un résumé d'une phrase obtient l'essentiel du même comportement, mais le skill ajoute les détails du parcours logique et du marquage prototype.