Expo Skill Eval

Was macht Expo Skill Eval?

Bewertet Skills in plugins/expo/skills/ hinsichtlich Auslösegenauigkeit, generierter Codequalität und/oder Laufzeit-Rendering in Expo Go.

Anforderungen: macOS mit Xcode (iOS-Simulatoren), Android SDK mit mindestens einem AVD und bun. Es wird keine weitere Geräte-Tooling vorausgesetzt.

Arbeitsbereichs-Stammverzeichnis: /private/tmp/expo-skill-eval-<skill-name>/iteration-N/ (z. B. /private/tmp/expo-skill-eval-expo-ui/iteration-4/).

Vor Beginn – Umfang klären

Bestätige alle folgenden Punkte im Voraus, bevor jegliche Pipeline-Arbeit beginnt – überspringe keinen (überspringe einen Punkt nur, wenn die Anfrage diese Wahl bereits angibt). Bündele sie in AskUserQuestion-Aufrufe mit ≤4 Fragen pro Aufruf, in dieser Reihenfolge:

1. Welcher Skill evaluiert werden soll (falls nicht aus der Anfrage ersichtlich).
2. Eingabeaufforderungen – welche Eingabeaufforderungen die Evaluierung steuern. Integrierte Eingabeaufforderungen (aus den Evaluierungsfällen des Skills) sind standardmäßig alle vorausgewählt; entferne eine, füge eine benutzerdefinierte Texteingabeaufforderung hinzu oder erzeuge eine aus einem hochgeladenen Screenshot (eine Ziel-UI, die der Skill reproduzieren muss). Siehe Eingabeaufforderungen unten.
3. Was überprüft werden soll – eine Mehrfachauswahl von drei Optionen: Laufzeit + Screenshots / Auslösegenauigkeit / Code-Prüfungen (kein Gerät). Siehe Was überprüft werden soll unten.
4. Expo SDK – neueste (Standard, automatisch erkannt) oder eine festgelegte Version.
5. Runner – Expo Go (Standard) oder Development Build.
6. Plattformen – iOS / Android / Web (biete immer alle drei an).
7. Berechtigungs-Flag für claude -p – skip-permissions (Standard) oder accept-edits.
8. Viewer-Bereitstellung – nur lokal (Standard) oder ein teilbares Artifact veröffentlichen.
9. Wenn Auslösegenauigkeit ausgewählt ist – bestätige, dass das veröffentlichte expo-Plugin deaktiviert (oder nicht installiert) ist.

Jeder Punkt wird unten ausführlich beschrieben. Die Punkte 4–6 (SDK, Runner, Plattformen) passen natürlich in einen einzigen AskUserQuestion-Aufruf.

Wenn der zu evaluierende Skill nicht aus der Anfrage hervorgeht, liste die verfügbaren Skills aus plugins/expo/skills/ auf und frage, welcher evaluiert werden soll.

Wie der getestete Skill geladen wird – zwei Mechanismen, einer pro Phase (wähle nicht global einen aus): Executor-Läufe referenzieren ihn über den Dateipfad (SKILL_PATH = plugins/expo/skills/<skill>/SKILL.md, explizit gelesen), während die Trigger-Evaluierung ihn als Plugin lädt (--plugin-dir plugins/expo, sodass das Modell ihn automatisch anhand seiner Beschreibung auswählen kann). Beide zeigen auf die lokale, im Repository befindliche Version – das ist, was du evaluierst. Du benötigst kein spezielles Flag, um die Harness-Sitzung selbst zu starten (der Harness findet den Skill über den Repository-Pfad); die Mechanismen gelten für die von ihm erzeugten claude -p-Subprozesse. Siehe Schritte 1 und 3, warum sich die Phasen unterscheiden. Eine Vorab-Prüfung (erforderlich, wenn die Trigger-Evaluierung im Umfang enthalten ist): Wenn das veröffentlichte expo-Plugin installiert/aktiviert ist, deaktiviere es (über /plugin) bevor du den Harness startest und reaktiviere es danach. Eine einzige Deaktivierung ist eine globale Konfigurationsänderung, die sowohl von dieser Sitzung als auch von den erzeugten claude -p-Subprozessen übernommen wird. Warum dies für die Trigger-Evaluierung erforderlich ist: Diese Phase lädt den lokalen Skill über --plugin-dir, und ein zweites installiertes expo kollidiert damit – das Modell könnte das veröffentlichte expo:expo-ui auslösen, und da die Erkennung nur den Tool-Call-Namen sieht, würdest du stillschweigend die veröffentlichte Beschreibung anstelle deiner lokalen Änderungen bewerten (die Kollision könnte auch einfach einen Fehler verursachen). Die Executor-/Laufzeit-/Statischen Phasen sind nicht betroffen – sie lesen den getesteten Skill über seinen lokalen SKILL_PATH ohne --plugin-dir – daher kann ein Lauf ohne Trigger-Evaluierung die Deaktivierung überspringen. Das Deaktivieren von expo deaktiviert nicht expo-skill-eval (ein eigenständiges Projekt-Skill, nicht Teil des expo-Plugins), sodass der Harness verfügbar bleibt.

Mache dies dem Benutzer als explizite Vorab-Bestätigung deutlich – genauso, wie du bestätigst, welcher Skill evaluiert werden soll. Wenn die Trigger-Evaluierung im Umfang enthalten ist, bitte den Benutzer zu bestätigen, dass das veröffentlichte expo-Plugin deaktiviert (oder nicht installiert) ist, bevor du mit Schritt 1 beginnst; falls es noch aktiviert ist, pausiere und lass es den Benutzer über /plugin deaktivieren. Führe die Trigger-Evaluierung erst durch, wenn der Benutzer dies bestätigt – der Harness kann installierte Plugins nicht zuverlässig selbst erkennen (das Lesen der globalen Plugin-Konfiguration oder claude plugin list würde eine Eingabeaufforderung auslösen), daher handelt es sich um eine manuelle Bestätigung, keine automatische Prüfung.

Wähle die Eingabeaufforderungen – integriert, benutzerdefiniert oder einen Ziel-Screenshot. Die Eingabeaufforderungen sind die Eingaben, die den Executor steuern (mit Skill und ohne Skill); sie sind getrennt von dem, was du überprüfst. Bestätige sie mit AskUserQuestion (überspringe, wenn die Anfrage bereits eine Eingabeaufforderung nennt):

• Integrierte Eingabeaufforderungen – repräsentative Eingabeaufforderungen, die du durch Lesen des getesteten Skills (seine SKILL.md + references/) und references/runtime-matrix.md generierst, die die Standard-Anwendungsfälle des Skills abdecken. (Wenn der Skill bereits Evaluierungsfälle unter evals/evals.json enthält, nimm auch deren prompt-Felder auf – aber die meisten Skills haben das nicht, daher leitest du sie normalerweise ab.) Wähle alle voraus, sodass der Standardlauf die Standardfälle des Skills trainiert; lass den Benutzer beliebige abwählen.
• Benutzerdefinierte Texteingabeaufforderung – eine einmalige Eingabeaufforderung, die der Benutzer eingibt. Verwende keinen dedizierten Optionsslot dafür: AskUserQuestion fügt automatisch einen „Gib etwas ein“ / Sonstiges-Eintrag hinzu, und alles dort Eingegebene wird zu einem benutzerdefinierten Textfall.
• Erzeuge aus einem hochgeladenen Screenshot – der Benutzer gibt den Pfad zu einem Ziel-Screenshot an (eine zu reproduzierende UI). Dem Executor wird gesagt, er solle ihn öffnen – claude -p liest PNGs mit seinem Read-Tool – und eine dazu passende App erstellen; der Fall zeichnet den Pfad als reference_image auf, und die Bewertung vergleicht die generierte App mit diesem Ziel (Schritt 6). Dies ist der stärkste visuelle Test für ein UI-Skill: „Erstelle das.“

Beachte das 4-Optionen-pro-Frage-Limit von AskUserQuestion mit dieser Priorität (der zu vermeidende Fehler: die Upload-Option wird stillschweigend fallen gelassen, sobald die vier Slots voll sind):

1. Reserviere immer einen Slot für „Erzeuge aus einem hochgeladenen Screenshot“. Es ist der ganze Sinn der visuellen Evaluierung und darf niemals die Option sein, die wegfällt.
2. Füge keine explizite Option „Benutzerdefinierte Texteingabeaufforderung“ hinzu – der automatische Eintrag „Gib etwas ein“ / Sonstiges deckt dies bereits ab.
3. **Fülle die verbleibenden ≤3 Slots mit den integrierten/repräsentativen Eingabeaufforderungen, vorausgewählt. Falls es mehr als 3 gibt, fasse sie zu einer vorausgewählten Option „Alle integrierten Eingabeaufforderungen (Standard)“ zusammen und biete in einer kurzen Nachfrage die Auswahl einer Teilmenge an, sodass die Upload-Option noch passt.

Präsentiere es als Mehrfachauswahl. Wenn „Erzeuge aus einem hochgeladenen Screenshot“ ausgewählt wird, frage in einer Nachfrage nach dem Pfad zum Zielbild. Jede ausgewählte Eingabeaufforderung (integriert, getippt oder Bild) wird zu einem Evaluierungsfall (ausgeführt mit und ohne Skill).

Bestätige immer, was überprüft werden soll, es sei denn, die Anfrage macht dies eindeutig. Präsentiere diese Optionen und lass den Benutzer eine oder mehrere auswählen (Standardeinstellungen fett basierend auf dem Eintrag des Skills in references/runtime-matrix.md):

Option	Was sie tut	Wann als Standard vorschlagen
Laufzeit + Screenshots	Vollständige Pipeline: Fixture → Executor → Statische Prüfung → App auf iOS/Android ausführen und screenshoten. Der Runner (Expo Go oder Dev Build) ist eine separate Frage – benenne ihn hier nicht.	Standard für jeden Skill, der einen App-Bildschirm rendert (die expo-go/dev-build-Zeilen in references/runtime-matrix.md). Erfordert einen gestarteten Simulator/Emulator.
Auslösegenauigkeit	Führe realistische Eingabeaufforderungen über claude -p aus, überprüfe, ob der Skill gelesen wird. Misst den Recall (nur Soll-auslösende Abfragen).	Immer als eigenständige Prüfung nützlich.
Code-Prüfungen (kein Gerät)	tsc --noEmit + diff-bewusstes Lint + expo export, plus der Bewerter prüft den generierten Code gegen alle von dir bereitgestellten benutzerdefinierten Erwartungen. Kein Gerät.	Standard für static-only- und n/a-Skills und immer dann, wenn du Codemuster überprüfen möchtest (korrekter Importpfad, ein Host-Wrapper, …), ohne die App auszuführen.
Präsentiere diese als EINE Mehrfachauswahlfrage – „Was möchtest du überprüfen?“ Dies sind Bewertungsdimensionen (wie beurteilt wird, was erstellt wird) – unterscheiden sich von der Phase der Eingabeaufforderungen (was erstellt werden soll). Der Benutzer kann jede Kombination wählen. Wenn eine Eingabeaufforderung ein hochgeladener Screenshot ist (siehe Eingabeaufforderungen), schließe „Laufzeit + Screenshots“ ein, damit der Harness die generierte App erfasst und der Bewerter sie mit dem Ziel vergleichen kann.

Lies references/runtime-matrix.md, um den Standardmodus des Skills zu finden, bevor du einen Vorschlag machst. Wenn die Anfrage bereits einen Modus angibt (z. B. „nur prüfen, ob er auslöst“, „auf dem Gerät ausführen“), überspringe die Frage und fahre fort.

Wähle die Expo SDK-Version – einmal, zu Beginn. Erkenne die neueste mit bash /abs/path/expo-skill-eval/scripts/latest-sdk.sh (es gibt die Hauptversion aus, z. B. 56; intern verwendet es bun, um npm view expo dist-tags --json auszuführen und die Hauptversion über JSON.parse/semver zu lesen, und dies wird von der Bash-Skript-Regel abgedeckt – führe also die Registry-Abfrage nicht selbst inline aus, was eine Eingabeaufforderung auslösen würde). Bestätige dann mit AskUserQuestion: Standardmäßig auf diese neueste SDK setzen oder den Benutzer eine ältere festlegen lassen (z. B. um ein versionsspezifisches Problem zu reproduzieren). Verwende die gewählte Version überall dort, wo das Fixture erstellt wird – übergib sie als <sdk>-Argument an make-fixture.sh und schreibe sie in den runtime.sdk jedes Evaluierungsfalls. Wenn die Anfrage bereits eine Version nennt („eval auf SDK 54“), überspringe die Erkennung und verwende sie.

Standardmäßig die neueste Version verwenden – sie bleibt kompatibel mit dem Expo Go, das expo start auf dem Gerät installiert. Das Festlegen einer SDK, die älter als das installierte Expo Go auf dem Gerät ist, führt dazu, dass expo start versucht, die Eingabeaufforderung „Empfohlene Expo Go-Version installieren?“ anzuzeigen; ohne TTY (die Snapshot-Skripte lesen stdin von /dev/null) stirbt es mit Input is required, but 'npx expo' is in non-interactive mode und jeder Snapshot schlägt fehl. Lege also nur dann eine ältere SDK fest, wenn du auch ein passendes Expo Go auf dem Simulator/Emulator vorinstallierst – ansonsten bleib bei der neuesten.

Wähle den Runner – Expo Go (Standard) oder einen Development Build. Frage mit AskUserQuestion (überspringe, wenn die Anfrage bereits angibt, welcher):

• Expo Go (Standard) – die Snapshot-Skripte führen die App mit expo start --ios / expo start --android unverändert aus. Schnell (keine native Kompilierung) und es führt alles aus, was Expo Go bündelt (einschließlich @expo/ui ab SDK 56+). Kann keinen benutzerdefinierten nativen Code ausführen (expo-modules, config plugins, native Abhängigkeiten, die nicht in Expo Go sind).
• Development Build – die Snapshot-Skripte führen stattdessen expo run:ios / expo run:android aus und kompilieren einen nativen Dev-Client pro Fixture. Verwende dies für Skills, deren Ausgabe benutzerdefinierten nativen Code benötigt (die Fälle, die sonst static-only wären). Viel langsamer – expo run erstellt vor und kompiliert nativ jedes Fixture (Minuten, besonders beim ersten) und benötigt die vollständige iOS/Android-Build-Toolchain – wähle es also nur, wenn der Skill tatsächlich nativen Code erfordert. Speicherintensiv: Der native Build jedes Fixtures ist mehrere GB groß. Die Snapshot-Phase führt nach jedem Fixture clean-fixture.sh aus, um die Spitzennutzung auf ~einen Build zu begrenzen, bevorzuge aber dennoch weniger Evaluierungsfälle und eine einzelne Plattform für Dev-Build-Läufe und halte ein paar GB frei. clean-fixture.sh entfernt die Build-Ausgabe pro Fixture (node_modules, ios, android, .expo, dist und das iOS DerivedData des Fixtures) und behält den App-Quellcode + Git. Der Hebel für Dev-Build-Speicher ist weniger Evaluierungsfälle + eine Plattform – es gibt nur die Build-Ausgabe pro Fixture frei und berührt niemals gemeinsame Abhängigkeits-Caches, sodass nichts erneut heruntergeladen wird.

Übergib die Wahl an die Snapshot-Skripte über die Umgebungsvariable EXPO_SKILL_EVAL_RUNNER (expo-go Standard oder dev-build) und spiegele sie im runtime.mode jedes Evaluierungsfalls wider (expo-go oder dev-build). Siehe Schritt 5.

Wähle die Plattformen – frage immer, unabhängig vom Skill. Biete iOS / Android / Web (Mehrfachauswahl) mit AskUserQuestion an; Standardmäßig iOS + Android, aber biete immer Web als Option an – filtere nicht vorab nach Skill. Web ist für die meisten Skills eine gültige Wahl: Die universellen Komponenten von @expo/ui (Host, Row, Column, Button, List, …) rendern im Web, ebenso wie expo-dom, NativeWind/Tailwind, API-Routen und normales React Native. Das Einzige, was im Web nicht angezeigt wird, ist ein plattformspezifischer nativer Baum (@expo/ui/swift-ui oder @expo/ui/jetpack-compose), der dort leer rendert – und diese Leere ist selbst ein nützliches Signal, also ist es immer noch die Entscheidung des Benutzers. Web läuft über snapshot-web.sh (expo start --web + Playwright/Chromium) unabhängig vom Runner (expo run ist nur nativ; es gibt keinen Web-Dev-Build) und ist der am wenigsten genutzte Pfad. Schreibe die gewählte Menge in das runtime.platforms jedes Evaluierungsfalls und lasse run_snapshots.py sie durchlaufen.

Bestätige, wie claude -p-Subprozesse ausgeführt werden – einmal, vor Beginn. Frage mit AskUserQuestion, ob sie mit --dangerously-skip-permissions ausgeführt werden dürfen, und wende dann die gleiche Antwort auf jeden Subprozess dieses Laufs an (frage niemals während des Laufs erneut):

• Berechtigungen überspringen (empfohlen) – übergib --dangerously-skip-permissions. Jeder Subprozess läuft unbeaufsichtigt in einem Wegwerf-Fixture unter /private/tmp/expo-skill-eval-* und kann Dateien schreiben und Setup-Befehle ohne Eingabeaufforderung ausführen.
• Nur Bearbeitungen akzeptieren – übergib stattdessen --permission-mode acceptEdits. Bash/Installationen werden automatisch abgelehnt (kein TTY), daher können einige Evaluierungen möglicherweise nur teilweise Ergebnisse liefern.

Ein nacktes claude -p ohne beide Flags kann überhaupt keine Dateien schreiben. Wenn die Anfrage bereits eine Präferenz angibt („Berechtigungen überspringen“, „verwende das gefährliche Flag nicht“), überspringe die Frage.

Bestätige, wie die Ergebnis-Viewer bereitgestellt werden – einmal, zu Beginn. Die Veröffentlichung auf claude.ai ist nach außen gerichtet, daher niemals während des Laufs überraschend durchführen; frage im selben AskUserQuestion zu Beginn (zusammen mit dem Berechtigungs-Flag):

• Nur lokal (Standard) – generate_viewer.py schreibt viewer.html und öffnet es im lokalen Browser. Nichts verlässt den Rechner.
• Teilbares Artifact veröffentlichen – zusätzlich den Viewer als claude.ai Artifact (eine standardmäßig private Webseite, die der Benutzer mit Teammitgliedern teilen kann) ganz am Ende rendern. Führe dies nur durch, wenn der Benutzer hier zustimmt.

Wenn die Anfrage bereits angibt, ob geteilt/veröffentlicht werden soll, überspringe die Frage. Siehe den Abschnitt Viewer für die Veröffentlichungsmechanik.

Evaluierungsfall-Schema

Du generierst die Evaluierungsfälle des Laufs – einen pro gewählter Eingabeaufforderung – und schreibst sie in <workspace>/iteration-N/evals.json (der Viewer liest sie von dort). Jeder Fall e...