Eval de habilidades de Expo

¿Qué hace Eval de habilidades de Expo?

Evalúa las habilidades en plugins/expo/skills/ para determinar la precisión del activador, la calidad del código generado y/o el renderizado en tiempo de ejecución en Expo Go.

Requisitos: macOS con Xcode (simuladores de iOS), Android SDK con al menos un AVD y bun. No se asume ninguna otra herramienta de dispositivo.

Directorio de trabajo: /private/tmp/expo-skill-eval-<nombre-de-habilidad>/iteration-N/ (ej. /private/tmp/expo-skill-eval-expo-ui/iteration-4/).

Antes de comenzar: aclarar el alcance

Confirma todo lo siguiente de antemano, antes de cualquier trabajo en el pipeline; no omitas ninguno (omite un elemento solo si la solicitud ya indica esa elección). Agrúpalos en llamadas AskUserQuestion de ≤4 preguntas cada una, en este orden:

1. Qué habilidad evaluar (si no está claro en la solicitud).
2. Indicaciones: qué indicaciones impulsan la evaluación. Las indicaciones incorporadas (de los casos de evaluación de la habilidad) están preseleccionadas todas; puedes eliminar alguna, agregar una indicación de texto personalizada o crear una a partir de una captura de pantalla subida (una interfaz de usuario objetivo que la habilidad debe reproducir). Consulta la sección Indicaciones más abajo.
3. Qué verificar: una selección múltiple de tres opciones: Runtime + capturas de pantalla / Precisión del activador / Verificaciones de código (sin dispositivo). Consulta Qué verificar más abajo.
4. SDK de Expo: el último (predeterminado, detectado automáticamente) o una versión fija.
5. Ejecutor: Expo Go (predeterminado) o compilación de desarrollo.
6. Plataformas: iOS / Android / web (ofrece siempre las tres).
7. Indicador de permiso para claude -p: omitir permisos (predeterminado) o aceptar ediciones.
8. Entrega del visor: solo local (predeterminado) o publicar un Artefacto compartible.
9. Si se selecciona la precisión del activador: confirma que el plugin expo publicado está deshabilitado (o no instalado).

Cada uno se detalla a continuación. Los elementos 4–6 (SDK, ejecutor, plataformas) encajan naturalmente en una sola llamada AskUserQuestion.

Si la habilidad a evaluar no está clara en la solicitud, enumera las habilidades disponibles de plugins/expo/skills/ y pregunta cuál evaluar.

Cómo se carga la habilidad bajo prueba: dos mecanismos, uno por fase (no elijas uno globalmente): el ejecutor la referencia por ruta de archivo (SKILL_PATH = plugins/expo/skills/<skill>/SKILL.md, leída explícitamente), mientras que la evaluación del activador la carga como un plugin (--plugin-dir plugins/expo, para que el modelo pueda seleccionarla automáticamente a partir de su descripción). Ambos apuntan a la versión local, dentro del repositorio: eso es lo que estás evaluando. No necesitas ningún indicador especial para iniciar la sesión del arnés en sí (el arnés encuentra la habilidad por la ruta del repositorio); los mecanismos se aplican a los subprocesos claude -p que genera. Consulta los pasos 1 y 3 para saber por qué cada fase difiere. Una verificación previa a la ejecución (requerida cuando la evaluación del activador está en el alcance): si el plugin expo publicado está instalado/habilitado, desactívalo (mediante /plugin) antes de lanzar el arnés y vuelve a activarlo después. Una sola desactivación es un cambio de configuración global que heredan tanto esta sesión como los subprocesos claude -p generados. Por qué es necesario para la evaluación del activador: esa fase carga la habilidad local mediante --plugin-dir, y un segundo expo instalado colisiona con ella: el modelo puede activar el expo:expo-ui publicado, y dado que la detección solo ve el nombre de la llamada a la herramienta, puntuarías silenciosamente la descripción publicada en lugar de tus ediciones locales (la colisión también podría generar un error). Las fases ejecutor / runtime / estático no se ven afectadas: leen la habilidad bajo prueba por su SKILL_PATH local sin --plugin-dir, por lo que una ejecución sin evaluación del activador puede omitir la desactivación. Deshabilitar expo no deshabilita expo-skill-eval (una habilidad de proyecto independiente, no parte del plugin expo), por lo que el arnés sigue disponible.

Presenta esto al usuario como una confirmación explícita upfront: de la misma manera que confirmas qué habilidad evaluar. Cuando la evaluación del activador está en el alcance, pide al usuario que confirme que el plugin expo publicado está deshabilitado (o no instalado) antes de comenzar el paso 1; si todavía está habilitado, haz una pausa y pídele que lo deshabilite mediante /plugin. No ejecutes la evaluación del activador hasta que confirmen; el arnés no puede detectar de manera confiable los plugins instalados por sí mismo (leer la configuración global de plugins o claude plugin list generaría una solicitud), por lo que esto es una confirmación manual, no una verificación automática.

Elige las indicaciones: incorporadas, personalizadas o una captura de pantalla objetivo. Las indicaciones son las entradas que impulsan el ejecutor (con habilidad y sin habilidad); son independientes de lo que verificas. Confírmalas con AskUserQuestion (omite si la solicitud ya nombra una indicación):

• Indicaciones incorporadas: indicaciones representativas que generas al leer la habilidad bajo prueba (su SKILL.md + references/) y references/runtime-matrix.md, que cubren los casos de uso estándar de la habilidad. (Si la habilidad ya incluye casos de evaluación en evals/evals.json, incorpora sus campos prompt también, pero la mayoría de las habilidades no lo hacen, por lo que normalmente las derivas). Preselecciona todas para que la ejecución predeterminada ejercite los casos estándar de la habilidad; permite al usuario deseleccionar cualquiera.
• Indicación de texto personalizada: una indicación única que el usuario escribe. No dediques una ranura de opción dedicada a esto: AskUserQuestion agrega automáticamente una entrada "Escribe algo" / Otro, y cualquier texto escrito allí se convierte en un caso de texto personalizado.
• Crear a partir de una captura de pantalla subida: el usuario proporciona la ruta a una captura de pantalla objetivo (una interfaz de usuario a reproducir). Se le dice al ejecutor que la abra — claude -p lee PNG con su herramienta Read — y construya una aplicación que coincida; el caso registra la ruta como reference_image, y la calificación compara la aplicación generada con ese objetivo (paso 6). Esta es la prueba visual más sólida para una habilidad de UI: "construye esto".

Respeta el límite de 4 opciones por pregunta de AskUserQuestion con esta prioridad (el error a evitar: la opción de subida se descarta silenciosamente una vez que los cuatro espacios se llenan):

1. Reserva siempre un espacio para "Crear a partir de una captura de pantalla subida". Es el objetivo principal de la evaluación visual y nunca debe ser la opción que se descarte.
2. No agregues una opción explícita de "Indicación de texto personalizada" — la entrada automática "Escribe algo" / Otro ya la cubre.
3. Llena los ≤3 espacios restantes con las indicaciones incorporadas/representativas, preseleccionadas. Si hay más de 3, combínalas en una opción preseleccionada "Todas las indicaciones incorporadas (predeterminado)" y ofrece la selección de subconjuntos en un seguimiento breve, para que la opción de subida aún encaje.

Preséntalo como una selección múltiple. Cuando se elige "Crear a partir de una captura de pantalla subida", pregunta por la ruta de la imagen objetivo en un seguimiento. Cada indicación seleccionada (incorporada, escrita o imagen) se convierte en un caso de evaluación (ejecutado con habilidad y sin habilidad).

Confirma siempre qué verificar a menos que la solicitud lo haga inequívoco. Presenta estas opciones y permite al usuario elegir una o más (los valores predeterminados están en negrita según la entrada de references/runtime-matrix.md de la habilidad):

Opción	Qué hace	Cuándo sugerir como predeterminado
Runtime + capturas de pantalla	Pipeline completo: fixture → ejecutor → puerta estática → ejecutar la aplicación en iOS/Android y capturarla. El ejecutor (Expo Go o compilación de desarrollo) es una pregunta separada; no lo nombres aquí.	Predeterminado para cualquier habilidad que renderice una pantalla de aplicación (las filas expo-go/dev-build en references/runtime-matrix.md). Requiere un simulador/emulador iniciado.
Precisión del activador	Ejecuta indicaciones realistas mediante claude -p, verifica si se lee la habilidad. Mide el recall (solo consultas que deberían activarse).	Siempre útil como verificación independiente.
Verificaciones de código (sin dispositivo)	tsc --noEmit + lint con detección de diferencias + expo export, además el calificador verifica el código generado contra cualquier expectativa personalizada que proporciones. Sin dispositivo.	Predeterminado para habilidades static-only y n/a, y siempre que quieras verificar patrones de código (ruta de importación correcta, un wrapper Host, …) sin ejecutar la aplicación.
Preséntalos como UNA pregunta de selección múltiple — "¿Qué quieres verificar?" Estos son dimensiones de calificación (cómo juzgar lo que se construye), distintas de la fase de Indicaciones (qué construir). El usuario puede elegir cualquier combinación. Cuando una indicación es una captura de pantalla subida (consulta Indicaciones), incluye "Runtime + capturas de pantalla" para que el arnés capture la aplicación generada y el calificador pueda puntuarla contra el objetivo.

Lee references/runtime-matrix.md para encontrar el modo predeterminado de la habilidad antes de sugerir. Si la solicitud ya especifica un modo (ej. "solo verifica si se activa", "ejecútalo en el dispositivo"), omite la pregunta y procede.

Elige la versión del SDK de Expo — una vez, upfront. Detecta la última con bash /abs/path/expo-skill-eval/scripts/latest-sdk.sh (imprime la versión principal, ej. 56; internamente usa bun para ejecutar npm view expo dist-tags --json y leer la principal mediante JSON.parse/semver, y está cubierto por la regla de scripts bash, así que no ejecutes la consulta del registro en línea tú mismo, lo que generaría una solicitud). Luego confirma con AskUserQuestion: por defecto, ese SDK más reciente, o permite al usuario fijar uno más antiguo (ej. para reproducir un problema específico de una versión). Usa la versión elegida en todos los lugares donde se construya el fixture — pásala como argumento <sdk> a make-fixture.sh y escríbela en el runtime.sdk de cada caso de evaluación. Si la solicitud ya nombra una versión ("evalúa en SDK 54"), omite la detección y úsala.

Por defecto, usa la última — se mantiene compatible con Expo Go que expo start instala en el dispositivo. Fijar un SDK anterior al Expo Go instalado en el dispositivo hace que expo start intente solicitar "¿Instalar la versión recomendada de Expo Go?"; sin TTY (los scripts de instantánea leen stdin desde /dev/null) falla con Input is required, but 'npx expo' is in non-interactive mode y cada instantánea falla. Por lo tanto, solo fija un SDK anterior cuando también preinstales un Expo Go compatible en el simulador/emulador; de lo contrario, mantén la última versión.

Elige el ejecutor: Expo Go (predeterminado) o una compilación de desarrollo. Pregunta con AskUserQuestion (omite si la solicitud ya indica cuál):

• Expo Go (predeterminado): los scripts de instantánea ejecutan la aplicación con expo start --ios / expo start --android tal cual. Rápido (sin compilación nativa) y ejecuta cualquier cosa que Expo Go agrupe (incluyendo @expo/ui en SDK 56+). No puede ejecutar código nativo personalizado (módulos expo, plugins de configuración, dependencias nativas no incluidas en Expo Go).
• Compilación de desarrollo: los scripts de instantánea ejecutan expo run:ios / expo run:android en su lugar, compilando un cliente de desarrollo nativo por fixture. Úsalo para habilidades cuya salida necesite código nativo personalizado (los casos que de otro modo serían static-only). Mucho más lento — expo run precompila y compila nativamente cada fixture (minutos, especialmente la primera vez), y necesita la cadena de herramientas de compilación completa de iOS/Android — así que solo elígelo cuando la habilidad realmente requiera código nativo. Pesado en disco: la compilación nativa de cada fixture es de varios GB. La fase de instantánea ejecuta clean-fixture.sh después de cada fixture para mantener el uso máximo en aproximadamente una compilación, pero aún es preferible tener menos casos de evaluación y una sola plataforma para ejecuciones de compilación de desarrollo, y mantener unos pocos GB libres. clean-fixture.sh elimina la salida de la compilación por fixture (node_modules, ios, android, .expo, dist y los DerivedData de iOS del fixture) y mantiene el código fuente de la aplicación + git. El control para el disco en compilaciones de desarrollo es menos casos de evaluación + una plataforma — solo recupera la salida de la compilación por fixture y nunca toca los cachés de dependencias compartidas, por lo que nada se descarga de nuevo.

Pasa la elección a los scripts de instantánea mediante la variable de entorno EXPO_SKILL_EVAL_RUNNER (por defecto expo-go, o dev-build), y reflejarla en el runtime.mode de cada caso de evaluación (expo-go o dev-build). Consulta el paso 5.

Elige las plataformas — pregunta siempre, independientemente de la habilidad. Ofrece iOS / Android / web (selección múltiple) con AskUserQuestion; por defecto iOS + Android, pero siempre presenta web como opción — no filtres previamente por habilidad. Web es una opción válida para la mayoría de las habilidades: los componentes universales de @expo/ui (Host, Row, Column, Button, List, …) se renderizan en web, al igual que expo-dom, NativeWind/Tailwind, rutas de API y React Native simple. Lo único que no se mostrará en web es un árbol nativo específico de plataforma (@expo/ui/swift-ui o @expo/ui/jetpack-compose), que se renderiza en blanco allí — y ese blanco es una señal útil, por lo que sigue siendo decisión del usuario. Web se ejecuta mediante snapshot-web.sh (expo start --web + Playwright/Chromium) independientemente del ejecutor (expo run es solo nativo; no hay compilación de desarrollo web), y es la ruta menos ejercitada. Escribe el conjunto elegido en el runtime.platforms de cada caso de evaluación y haz que run_snapshots.py los recorra.

Confirma cómo se ejecutan los subprocesos claude -p — una vez, antes de comenzar. Pregunta con AskUserQuestion si pueden ejecutarse con --dangerously-skip-permissions, luego aplica la misma respuesta a cada subproceso de esta ejecución (nunca vuelvas a preguntar durante la ejecución):

• Omitir permisos (recomendado): pasa --dangerously-skip-permissions. Cada subproceso se ejecuta sin supervisión dentro de un fixture desechable en /private/tmp/expo-skill-eval-* y puede escribir archivos y ejecutar comandos de configuración sin solicitar confirmación.
• Solo aceptar ediciones: pasa --permission-mode acceptEdits en su lugar. Bash/instalaciones se deniegan automáticamente (sin TTY), por lo que algunas evaluaciones pueden producir resultados parciales.

Un claude -p simple sin ninguno de los dos indicadores no puede escribir archivos en absoluto. Si la solicitud ya indica una preferencia ("omitir permisos", "no uses el indicador peligroso"), omite la pregunta.

Confirma cómo entregar el visor de resultados — una vez, upfront. Publicar en claude.ai es hacia el exterior, así que nunca lo hagas durante la ejecución por sorpresa; pregunta en el mismo AskUserQuestion inicial (junto con el indicador de permiso):

• Solo local (predeterminado): generate_viewer.py escribe viewer.html y lo abre en el navegador local. Nada sale de la máquina.
• Publicar un Artefacto compartible: adicionalmente, renderiza el visor como un Artefacto de claude.ai (una página web privada por defecto que el usuario puede compartir con compañeros de equipo) al final. Solo haz esto si el usuario opta por ello aquí.

Si la solicitud ya dice si compartir/publicar, omite la pregunta. Consulta la sección Visor para conocer los mecanismos de publicación.

Esquema del caso de evaluación

Generas los casos de evaluación de la ejecución — uno por indicación elegida — y los escribes en <workspace>/iteration-N/evals.json (el visor los lee desde allí). Cada caso e

...