expo/expo-skill-eval

Évaluation de compétence Expo

Évalue les compétences dans plugins/expo/skills/ pour la précision des déclencheurs, la qualité du code généré et/ou le rendu d'exécution dans Expo Go.

Configuration requise : macOS avec Xcode (simulateurs iOS), SDK Android avec au moins un AVD, et bun. Aucun autre outil d'appareil n'est supposé.

Racine de l'espace de travail : /private/tmp/expo-skill-eval-<nom-compétence>/iteration-N/ (par exemple /private/tmp/expo-skill-eval-expo-ui/iteration-4/).

Avant de commencer — clarifier le périmètre

Confirmez tous les éléments suivants à l'avance, avant tout travail de pipeline — n'en sautez aucun (ne sautez un élément que si la demande indique déjà ce choix). Regroupez-les en appels AskUserQuestion de ≤4 questions chacun, dans cet ordre :

1. Quelle compétence évaluer (si ce n'est pas clair d'après la demande).
2. Invites — quelles invites pilotent l'évaluation. Les invites intégrées (issues des cas d'évaluation de la compétence) sont pré-sélectionnées toutes ; supprimez-en une, ajoutez une invite textuelle personnalisée, ou construisez à partir d'une capture d'écran téléchargée (une interface utilisateur cible que la compétence doit reproduire). Voir Invites ci-dessous.
3. Que vérifier — une sélection multiple de trois options : Exécution + captures d'écran / Précision des déclencheurs / Vérifications de code (sans appareil). Voir Que vérifier ci-dessous.
4. SDK Expo — dernière version (par défaut, détection automatique) ou une version épinglée.
5. Exécuteur — Expo Go (par défaut) ou build de développement.
6. Plateformes — iOS / Android / web (proposez toujours les trois).
7. Indicateur d'autorisation pour claude -p — ignorer les autorisations (par défaut) ou accepter les modifications.
8. Livraison du visualiseur — local uniquement (par défaut) ou publier un Artifact partageable.
9. Si la précision des déclencheurs est sélectionnée — confirmez que le plugin expo publié est désactivé (ou non installé).

Chacun est détaillé ci-dessous. Les éléments 4 à 6 (SDK, exécuteur, plateformes) tiennent naturellement dans un seul appel AskUserQuestion.

Si la compétence à évaluer n'est pas claire d'après la demande, listez les compétences disponibles dans plugins/expo/skills/ et demandez laquelle évaluer.

Comment la compétence testée est chargée — deux mécanismes, un par phase (ne choisissez pas un mécanisme globalement) : les exécuteurs de référence y accèdent par chemin de fichier (SKILL_PATH = plugins/expo/skills/<compétence>/SKILL.md, lecture explicite), tandis que l'évaluation des déclencheurs la charge comme un plugin (--plugin-dir plugins/expo, pour que le modèle puisse la sélectionner automatiquement à partir de sa description). Les deux pointent vers la version locale, dans le dépôt — c'est ce que vous évaluez. Vous n'avez pas besoin d'un indicateur spécial pour lancer la session du harnais elle-même (le harnais trouve la compétence par le chemin du dépôt) ; les mécanismes s'appliquent aux sous-processus claude -p qu'il génère. Voir les étapes 1 et 3 pour savoir pourquoi chaque phase diffère. Une vérification préalable (obligatoire lorsque l'évaluation des déclencheurs est dans le périmètre) : si le plugin expo publié est installé/activé, désactivez-le (via /plugin) avant de lancer le harnais et réactivez-le après. Une seule désactivation est un changement de configuration globale que cette session et les sous-processus claude -p générés héritent. Pourquoi c'est obligatoire pour l'évaluation des déclencheurs : cette phase charge la compétence locale via --plugin-dir, et un second expo installé entre en collision avec elle — le modèle pourrait déclencher le expo:expo-ui publié, et comme la détection ne voit que le nom de l'appel d'outil, vous noteriez silencieusement la description publiée au lieu de vos modifications locales (la collision pourrait aussi simplement générer une erreur). Les phases d'exécuteur / d'exécution / statique ne sont pas affectées — elles lisent la compétence testée par son SKILL_PATH local sans --plugin-dir — donc une exécution sans évaluation des déclencheurs peut ignorer la désactivation. Désactiver expo ne désactive pas expo-skill-eval (une compétence de projet autonome, ne faisant pas partie du plugin expo), donc le harnais reste disponible.

Présentez cela à l'utilisateur comme une confirmation explicite préalable — de la même manière que vous confirmez quelle compétence évaluer. Lorsque l'évaluation des déclencheurs est dans le périmètre, demandez à l'utilisateur de confirmer que le plugin expo publié est désactivé (ou non installé) avant de commencer l'étape 1 ; s'il est toujours activé, faites une pause et demandez-lui de le désactiver via /plugin. N'exécutez pas l'évaluation des déclencheurs tant qu'il n'a pas confirmé — le harnais ne peut pas détecter de manière fiable les plugins installés par lui-même (la lecture de la configuration globale du plugin ou claude plugin list générerait une invite), c'est donc une confirmation manuelle, pas une vérification automatique.

Choisissez les invites — intégrées, personnalisées ou une capture d'écran cible. Les invites sont les entrées qui pilotent l'exécuteur (avec compétence et sans compétence) ; elles sont distinctes de ce que vous vérifiez. Confirmez-les avec AskUserQuestion (sautez si la demande nomme déjà une invite) :

• Invites intégrées — des invites représentatives que vous générez en lisant la compétence testée (son SKILL.md + references/) et references/runtime-matrix.md, couvrant les cas d'utilisation standard de la compétence. (Si la compétence fournit déjà des cas d'évaluation sous evals/evals.json, intégrez leurs champs prompt aussi — mais la plupart des compétences ne le font pas, vous les dérivez donc généralement.) Pré-sélectionnez toutes pour que l'exécution par défaut exerce les cas standard de la compétence ; laissez l'utilisateur en désélectionner certaines.
• Invite textuelle personnalisée — une invite ponctuelle que l'utilisateur saisit. Ne consacrez pas un créneau d'option dédié à cela : AskUserQuestion ajoute automatiquement une entrée « Tapez quelque chose » / Autre, et tout ce qui est tapé devient un cas textuel personnalisé.
• Construire à partir d'une capture d'écran téléchargée — l'utilisateur donne le chemin d'une capture d'écran cible (une interface utilisateur à reproduire). L'exécuteur doit l'ouvrir — claude -p lit les PNG avec son outil Read — et construire une application qui lui correspond ; le cas enregistre le chemin comme reference_image, et la notation compare l'application générée à cette cible (étape 6). C'est le test visuel le plus fort pour une compétence d'interface utilisateur : « construis ceci. »

Respectez la limite de 4 options par question de AskUserQuestion avec cette priorité (l'erreur à éviter : l'option de téléchargement silencieusement abandonnée une fois les quatre créneaux remplis) :

1. Réservez toujours un créneau pour « Construire à partir d'une capture d'écran téléchargée. » C'est tout l'intérêt de l'évaluation visuelle et elle ne doit jamais être l'option qui est abandonnée.
2. N'ajoutez pas d'option explicite « Invite textuelle personnalisée » — l'entrée automatique « Tapez quelque chose » / Autre la couvre déjà.
3. Remplissez les ≤3 créneaux restants avec les invites intégrées/représentatives, pré-sélectionnées. S'il y en a plus de 3, regroupez-les en une option pré-sélectionnée « Toutes les invites intégrées (par défaut) » et proposez un sous-choix dans un appel court ultérieur, pour que l'option de téléchargement tienne toujours.

Présentez-le comme une sélection multiple. Lorsque « Construire à partir d'une capture d'écran téléchargée » est choisi, demandez le chemin de l'image cible dans un appel ultérieur. Chaque invite sélectionnée (intégrée, tapée ou image) devient un cas d'évaluation (exécuté avec compétence et sans compétence).

Confirmez toujours quoi vérifier sauf si la demande le rend sans ambiguïté. Présentez ces options et laissez l'utilisateur en choisir une ou plusieurs (les valeurs par défaut sont en gras en fonction de l'entrée references/runtime-matrix.md de la compétence) :

Option	Ce qu'elle fait	Quand la suggérer par défaut
Exécution + captures d'écran	Pipeline complet : fixture → exécuteur → passerelle statique → exécuter l'application sur iOS/Android et en faire une capture d'écran. L'exécuteur (Expo Go ou build de développement) est une question séparée — ne le nommez pas ici.	Par défaut pour toute compétence qui affiche un écran d'application (les lignes expo-go/dev-build dans references/runtime-matrix.md). Nécessite un simulateur/émulateur démarré.
Précision des déclencheurs	Exécutez des invites réalistes via claude -p, vérifiez si la compétence est lue. Mesure le rappel (requêtes qui doivent déclencher uniquement).	Toujours utile comme vérification autonome.
Vérifications de code (sans appareil)	tsc --noEmit + lint avec conscience des différences + expo export, et le correcteur vérifie le code généré par rapport à toutes les attentes personnalisées que vous fournissez. Pas d'appareil.	Par défaut pour les compétences static-only et n/a, et chaque fois que vous voulez vérifier des motifs de code (chemin d'importation correct, un wrapper Host, …) sans exécuter l'application.
Présentez-les comme UNE question à sélection multiple — « Que voulez-vous vérifier ? » Ce sont des dimensions de notation (comment juger ce qui est construit) — distinctes de la phase Invites (quoi construire). L'utilisateur peut choisir n'importe quelle combinaison. Lorsqu'une invite est une capture d'écran téléchargée (voir Invites), incluez « Exécution + captures d'écran » pour que le harnais capture l'application générée et que le correcteur puisse la noter par rapport à la cible.

Lisez references/runtime-matrix.md pour trouver le mode par défaut de la compétence avant de suggérer. Si la demande spécifie déjà un mode (par exemple « vérifie juste si elle déclenche », « exécute-la sur l'appareil »), sautez la question et continuez.

Choisissez la version du SDK Expo — une fois, au début. Détectez la dernière avec bash /abs/path/expo-skill-eval/scripts/latest-sdk.sh (elle affiche la version majeure, par exemple 56 ; en interne, elle utilise bun pour exécuter npm view expo dist-tags --json et lire la majeure via JSON.parse/semver, et elle est couverte par la règle des scripts bash — donc n'exécutez pas la requête de registre en ligne vous-même, ce qui générerait une invite). Confirmez ensuite avec AskUserQuestion : par défaut, ce SDK le plus récent, ou laissez l'utilisateur épingler une version plus ancienne (par exemple pour reproduire un problème spécifique à une version). Utilisez la version choisie partout où la fixture est construite — passez-la comme argument <sdk> à make-fixture.sh et écrivez-la dans le champ runtime.sdk de chaque cas d'évaluation. Si la demande nomme déjà une version (« évaluer sur SDK 54 »), sautez la détection et utilisez-la.

Par défaut, la dernière version — elle reste compatible avec l'Expo Go qu'expo start installe sur l'appareil. Épingler un SDK plus ancien que l'Expo Go installé sur l'appareil fait qu'expo start tente de demander « Installer la version recommandée d'Expo Go ? » ; sans TTY (les scripts de capture lisent stdin depuis /dev/null), il échoue avec Input is required, but 'npx expo' is in non-interactive mode et chaque capture échoue. N'épinglez donc un SDK plus ancien que si vous pré-installez également un Expo Go correspondant sur le simulateur/émulateur — sinon restez avec la dernière version.

Choisissez l'exécuteur — Expo Go (par défaut) ou un build de développement. Demandez avec AskUserQuestion (sautez si la demande indique déjà lequel) :

• Expo Go (par défaut) — les scripts de capture exécutent l'application avec expo start --ios / expo start --android tel quel. Rapide (pas de compilation native), et il exécute tout ce qu'Expo Go bundle (y compris @expo/ui sur SDK 56+). Impossible d'exécuter du code natif personnalisé (expo-modules, plugins de configuration, dépendances natives non présentes dans Expo Go).
• Build de développement — les scripts de capture exécutent expo run:ios / expo run:android à la place, compilant un client de développement natif par fixture. Utilisez-le pour les compétences dont la sortie nécessite du code natif personnalisé (les cas qui seraient autrement static-only). Beaucoup plus lent — expo run pré-construit et compile nativement chaque fixture (minutes, surtout la première), et nécessite la chaîne d'outils de compilation iOS/Android complète — donc ne le choisissez que lorsque la compétence nécessite réellement du code natif. Lourd en disque : le build natif de chaque fixture fait plusieurs Go. La phase de capture exécute clean-fixture.sh après chaque fixture pour maintenir l'utilisation de pointe à environ un build, mais préférez quand même moins de cas d'évaluation et une plateforme unique pour les exécutions de build de développement, et gardez quelques Go libres. clean-fixture.sh supprime la sortie du build par fixture (node_modules, ios, android, .expo, dist, et le DerivedData iOS de la fixture) et conserve le code source de l'application + git. Le levier pour le disque de build de développement est moins de cas d'évaluation + une plateforme — il ne récupère que la sortie du build par fixture et ne touche jamais aux caches de dépendances partagés, donc rien n'est téléchargé à nouveau.

Passez le choix aux scripts de capture via la variable d'environnement EXPO_SKILL_EVAL_RUNNER (expo-go par défaut, ou dev-build), et reflétez-le dans le champ runtime.mode de chaque cas d'évaluation (expo-go ou dev-build). Voir l'étape 5.

Choisissez les plateformes — demandez toujours, quelle que soit la compétence. Proposez iOS / Android / web (sélection multiple) avec AskUserQuestion ; par défaut iOS + Android, mais présentez toujours le web comme option — ne filtrez pas par compétence. Le web est un choix valide pour la plupart des compétences : les composants universels d'@expo/ui (Host, Row, Column, Button, List, …) s'affichent sur le web, ainsi que expo-dom, NativeWind/Tailwind, les routes API, et React Native simple. La seule chose qui ne s'affichera pas sur le web est un arbre natif spécifique à une plateforme (@expo/ui/swift-ui ou @expo/ui/jetpack-compose), qui s'affiche vide — et ce vide est lui-même un signal utile, donc c'est toujours le choix de l'utilisateur. Le web s'exécute via snapshot-web.sh (expo start --web + Playwright/Chromium) indépendamment de l'exécuteur (expo run est natif uniquement ; il n'y a pas de build de développement web), et c'est le chemin le moins testé. Écrivez l'ensemble choisi dans le champ runtime.platforms de chaque cas d'évaluation et faites en sorte que run_snapshots.py les parcoure.

Confirmez comment les sous-processus claude -p s'exécutent — une fois, avant de commencer. Demandez avec AskUserQuestion s'ils peuvent s'exécuter avec --dangerously-skip-permissions, puis appliquez la même réponse à chaque sous-processus de cette exécution (ne demandez jamais à nouveau en cours d'exécution) :

• Ignorer les autorisations (recommandé) — passez --dangerously-skip-permissions. Chaque sous-processus s'exécute sans surveillance dans une fixture jetable sous /private/tmp/expo-skill-eval-* et peut écrire des fichiers et exécuter des commandes de configuration sans invite.
• Accepter les modifications uniquement — passez --permission-mode acceptEdits à la place. Les Bash/installations sont automatiquement refusées (pas de TTY), donc certaines évaluations peuvent produire une sortie partielle.

Un simple claude -p sans aucun des deux indicateurs ne peut pas du tout écrire de fichiers. Si la demande indique déjà une préférence (« ignorer les autorisations », « n'utilise pas l'indicateur dangereux »), sautez la question.

Confirmez comment livrer le visualiseur de résultats — une fois, au début. Publier sur claude.ai est tourné vers l'extérieur, donc ne le faites jamais en cours d'exécution par surprise ; demandez dans la même AskUserQuestion préalable (en même temps que l'indicateur d'autorisation) :

• Local uniquement (par défaut) — generate_viewer.py écrit viewer.html et l'ouvre dans le navigateur local. Rien ne quitte la machine.
• Publier un Artifact partageable — en plus, générez le visualiseur en un Artifact claude.ai (une page web privée par défaut que l'utilisateur peut partager avec ses collègues) à la toute fin. Ne le faites que si l'utilisateur l'accepte ici.

Si la demande indique déjà s'il faut partager/publier, sautez la question. Voir la section Visualiseur pour les mécanismes de publication.

Schéma du cas d'évaluation

Vous générez les cas d'évaluation de l'exécution — un par invite choisie — et les écrivez dans <workspace>/iteration-N/evals.json (le visualiseur les lit à partir de là). Chaque cas e

…[tronqué pour la traduction]