expo/expo-skill-eval

Avaliação de Habilidade Expo

Avalia habilidades em plugins/expo/skills/ quanto à precisão de acionamento, qualidade do código gerado e/ou renderização em tempo de execução no Expo Go.

Requisitos: macOS com Xcode (simuladores iOS), Android SDK com pelo menos um AVD e bun. Nenhuma outra ferramenta de dispositivo é assumida.

Raiz do espaço de trabalho: /private/tmp/expo-skill-eval-<skill-name>/iteration-N/ (ex.: /private/tmp/expo-skill-eval-expo-ui/iteration-4/).

Antes de começar — esclarecer o escopo

Confirme todos os itens a seguir antecipadamente, antes de qualquer trabalho no pipeline — não pule nenhum (pule um item apenas se a solicitação já declarar essa escolha). Agrupe-os em chamadas AskUserQuestion de ≤4 perguntas cada, nesta ordem:

1. Qual habilidade avaliar (se não estiver claro na solicitação).
2. Prompts — quais prompts direcionam a avaliação. Prompts embutidos (dos casos de avaliação da habilidade) são pré-selecionados todos; remova qualquer um, adicione um prompt de texto personalizado ou crie a partir de uma captura de tela carregada (uma IU alvo que a habilidade deve reproduzir). Veja Prompts abaixo.
3. O que verificar — uma seleção múltipla de três opções: Tempo de execução + capturas de tela / Precisão de acionamento / Verificações de código (sem dispositivo). Veja O que verificar abaixo.
4. SDK Expo — mais recente (padrão, detectado automaticamente) ou uma versão fixa.
5. Executor — Expo Go (padrão) ou build de desenvolvimento.
6. Plataformas — iOS / Android / web (sempre ofereça as três).
7. Sinalizador de permissão para claude -p — pular permissões (padrão) ou aceitar edições.
8. Entrega do visualizador — apenas local (padrão) ou publicar um Artifact compartilhável.
9. Se a precisão de acionamento for selecionada — confirme que o plugin expo publicado está desabilitado (ou não instalado).

Cada item é detalhado abaixo. Os itens 4–6 (SDK, executor, plataformas) cabem naturalmente em uma chamada AskUserQuestion.

Se a habilidade a avaliar não estiver clara na solicitação, liste as habilidades disponíveis de plugins/expo/skills/ e pergunte qual avaliar.

Como a habilidade em teste é carregada — dois mecanismos, um por fase (não escolha um globalmente): os executores de referência a referenciam por caminho de arquivo (SKILL_PATH = plugins/expo/skills/<skill>/SKILL.md, lido explicitamente), enquanto a avaliação de acionamento a carrega como um plugin (--plugin-dir plugins/expo, para que o modelo possa selecioná-la automaticamente por sua descrição). Ambos apontam para a versão local, no repositório — é isso que você está avaliando. Você não precisa de nenhum sinalizador especial para iniciar a sessão do harness em si (o harness encontra a habilidade pelo caminho do repositório); os mecanismos se aplicam aos subprocessos claude -p que ele gera. Veja as etapas 1 e 3 para saber por que cada fase difere. Uma verificação de pré-execução (obrigatória quando a avaliação de acionamento estiver no escopo): se o plugin expo publicado estiver instalado/habilitado, desabilite-o (via /plugin) antes de iniciar o harness e reabilite após. Uma única desabilitação é uma alteração de configuração global que tanto esta sessão quanto os subprocessos claude -p gerados herdam. Por que é obrigatório para a avaliação de acionamento: essa fase carrega a habilidade local via --plugin-dir, e um segundo expo instalado colide com ela — o modelo pode acionar o expo:expo-ui publicado, e como a detecção vê apenas o nome da chamada de ferramenta, você silenciosamente pontuaria a descrição publicada em vez de suas edições locais (a colisão também pode apenas gerar erro). As fases executor / tempo de execução / estático não são afetadas — elas leem a habilidade em teste por seu SKILL_PATH local sem --plugin-dir — portanto, uma execução sem avaliação de acionamento pode pular a desabilitação. Desabilitar expo não desabilita expo-skill-eval (uma habilidade de projeto independente, não parte do plugin expo), então o harness permanece disponível.

Apresente isso ao usuário como uma confirmação explícita inicial — da mesma forma que você confirma qual habilidade avaliar. Quando a avaliação de acionamento estiver no escopo, peça ao usuário para confirmar que o plugin expo publicado está desabilitado (ou não instalado) antes de você iniciar a etapa 1; se ainda estiver habilitado, pause e peça que o desabilitem via /plugin. Não execute a avaliação de acionamento até que eles confirmem — o harness não pode detectar plugins instalados de forma confiável por conta própria (ler a configuração global do plugin ou claude plugin list solicitaria), então esta é uma confirmação manual, não uma verificação automática.

Escolha os prompts — embutidos, personalizados ou uma captura de tela alvo. Os prompts são as entradas que direcionam o executor (com-habilidade e sem-habilidade); eles são separados do que você verifica. Confirme-os com AskUserQuestion (pule se a solicitação já nomear um prompt):

• Prompts embutidos — prompts representativos que você gera lendo a habilidade em teste (seu SKILL.md + references/) e references/runtime-matrix.md, cobrindo os casos de uso padrão da habilidade. (Se a habilidade já incluir casos de avaliação em evals/evals.json, incorpore seus campos prompt também — mas a maioria das habilidades não tem, então você geralmente os deriva.) Pré-selecione todos para que a execução padrão exercite os casos padrão da habilidade; deixe o usuário desmarcar qualquer um.
• Prompt de texto personalizado — um prompt único que o usuário digita. Não gaste um slot de opção dedicado nisso: AskUserQuestion adiciona automaticamente uma entrada "Digite algo" / Outro, e qualquer coisa digitada lá se torna um caso de texto personalizado.
• Criar a partir de uma captura de tela carregada — o usuário fornece o caminho para uma captura de tela alvo (uma IU a reproduzir). O executor recebe a instrução de abri-la — claude -p lê PNGs com sua ferramenta Read — e construir um aplicativo que a corresponda; o caso registra o caminho como reference_image, e a classificação compara o aplicativo gerado a esse alvo (etapa 6). Este é o teste visual mais forte para uma habilidade de IU: "construir isto."

Respeite o limite de 4 opções por pergunta do AskUserQuestion com esta prioridade (o bug a evitar: a opção de upload descartada silenciosamente quando os quatro slots se enchem):

1. Sempre reserve um slot para "Criar a partir de uma captura de tela carregada." É o objetivo principal da avaliação visual e nunca deve ser a opção descartada.
2. Não adicione uma opção explícita "Prompt de texto personalizado" — a entrada automática "Digite algo" / Outro já cobre.
3. Preencha os ≤3 slots restantes com os prompts embutidos/representativos, pré-selecionados. Se houver mais de 3, reduza-os a uma opção pré-selecionada "Todos os prompts embutidos (padrão)" e ofereça a seleção de subconjunto em um acompanhamento curto, para que a opção de upload ainda se encaixe.

Apresente como uma seleção múltipla. Quando "Criar a partir de uma captura de tela carregada" for escolhido, peça o caminho da imagem alvo em um acompanhamento. Cada prompt selecionado (embutido, digitado ou imagem) se torna um caso de avaliação (executado com-habilidade e sem-habilidade).

Sempre confirme o que verificar a menos que a solicitação o torne inequívoco. Apresente estas opções e deixe o usuário escolher uma ou mais (padrões em negrito com base na entrada references/runtime-matrix.md da habilidade):

Opção	O que faz	Quando sugerir como padrão
Tempo de execução + capturas de tela	Pipeline completo: fixture → executor → gate estático → executar o aplicativo no iOS/Android e capturar sua tela. O executor (Expo Go ou build de desenvolvimento) é uma pergunta separada — não o nomeie aqui.	Padrão para qualquer habilidade que renderize uma tela de aplicativo (as linhas expo-go/dev-build em references/runtime-matrix.md). Requer um simulador/emulador inicializado.
Precisão de acionamento	Executar prompts realistas via claude -p, verificar se a habilidade é lida. Mede recall (consultas que devem acionar apenas).	Sempre útil como uma verificação independente.
Verificações de código (sem dispositivo)	tsc --noEmit + lint sensível a diff + expo export, mais o avaliador verifica o código gerado em relação a quaisquer expectativas personalizadas que você fornecer. Sem dispositivo.	Padrão para habilidades static-only e n/a, e sempre que você quiser verificar padrões de código (caminho de importação correto, um wrapper Host, …) sem executar o aplicativo.
Apresente como UMA pergunta de seleção múltipla — "O que você quer verificar?" Estas são dimensões de classificação (como julgar o que é construído) — distintas da fase de Prompts (o que construir). O usuário pode escolher qualquer combinação. Quando um prompt é uma captura de tela carregada (veja Prompts), inclua "Tempo de execução + capturas de tela" para que o harness capture o aplicativo gerado e o avaliador possa pontuá-lo em relação ao alvo.

Leia references/runtime-matrix.md para encontrar o modo padrão da habilidade antes de sugerir. Se a solicitação já especificar um modo (ex.: "apenas verifique se ele aciona", "execute no dispositivo"), pule a pergunta e prossiga.

Escolha a versão do SDK Expo — uma vez, antecipadamente. Detecte a mais recente com bash /abs/path/expo-skill-eval/scripts/latest-sdk.sh (ela imprime a major, ex.: 56; internamente usa bun para executar npm view expo dist-tags --json e lê a major via JSON.parse/semver, e é coberta pela regra de scripts bash — então não execute a consulta de registro inline você mesmo, o que solicitaria). Em seguida, confirme com AskUserQuestion: padrão para esse SDK mais recente, ou deixe o usuário fixar uma versão mais antiga (ex.: para reproduzir um problema específico de versão). Use a versão escolhida em todos os lugares onde a fixture é construída — passe-a como o argumento <sdk> para make-fixture.sh e escreva-a em cada caso de avaliação em runtime.sdk. Se a solicitação já nomear uma versão ("avaliar no SDK 54"), pule a detecção e use-a.

Padrão para o mais recente — ele permanece compatível com o Expo Go que expo start instala no dispositivo. Fixar um SDK mais antigo que o Expo Go instalado no dispositivo faz com que expo start tente solicitar "Instalar a versão recomendada do Expo Go?"; sem TTY (os scripts de snapshot leem stdin de /dev/null) ele morre com Input is required, but 'npx expo' is in non-interactive mode e todo snapshot falha. Portanto, fixe um SDK mais antigo apenas quando você também pré-instalar um Expo Go correspondente no simulador/emulador — caso contrário, mantenha o mais recente.

Escolha o executor — Expo Go (padrão) ou um build de desenvolvimento. Pergunte com AskUserQuestion (pule se a solicitação já disser qual):

• Expo Go (padrão) — os scripts de snapshot executam o aplicativo com expo start --ios / expo start --android como está. Rápido (sem compilação nativa) e executa qualquer coisa que o Expo Go agrupa (incluindo @expo/ui no SDK 56+). Não pode executar código nativo personalizado (expo-modules, plugins de configuração, deps nativas não no Expo Go).
• Build de desenvolvimento — os scripts de snapshot executam expo run:ios / expo run:android em vez disso, compilando um cliente de desenvolvimento nativo por fixture. Use para habilidades cuja saída precisa de código nativo personalizado (os casos que seriam static-only). Muito mais lento — expo run pré-constroi e compila nativamente cada fixture (minutos, especialmente a primeira), e precisa de toda a cadeia de ferramentas de build iOS/Android — então escolha-o apenas quando a habilidade realmente exigir código nativo. Pesado em disco: a construção nativa de cada fixture tem vários GB. A fase de snapshot executa clean-fixture.sh após cada fixture para manter o uso de pico em ~uma construção, mas ainda prefira menos casos de avaliação e uma única plataforma para execuções de build de desenvolvimento, e mantenha alguns GB livres. clean-fixture.sh remove a saída da construção por fixture (node_modules, ios, android, .expo, dist e o DerivedData iOS da fixture) e mantém o código-fonte do aplicativo + git. A alavanca para disco de build de desenvolvimento é menos casos de avaliação + uma plataforma — ela apenas recupera a saída de construção por fixture e nunca toca em caches de dependência compartilhados, então nada é baixado novamente.

Passe a escolha para os scripts de snapshot via a variável de ambiente EXPO_SKILL_EVAL_RUNNER (expo-go padrão, ou dev-build), e reflita-a em cada caso de avaliação em runtime.mode (expo-go ou dev-build). Veja a etapa 5.

Escolha as plataformas — sempre pergunte, independentemente da habilidade. Ofereça iOS / Android / web (seleção múltipla) com AskUserQuestion; padrão para iOS + Android, mas sempre apresente web como uma opção — não pré-filtre por habilidade. Web é uma escolha válida para a maioria das habilidades: os componentes universais do @expo/ui (Host, Row, Column, Button, List, …) renderizam na web, assim como expo-dom, NativeWind/Tailwind, rotas de API e React Native puro. A única coisa que não aparecerá na web é uma árvore nativa específica de plataforma (@expo/ui/swift-ui ou @expo/ui/jetpack-compose), que renderiza em branco lá — e esse branco é um sinal útil por si só, então ainda é a decisão do usuário. Web executa via snapshot-web.sh (expo start --web + Playwright/Chromium) independentemente do executor (expo run é apenas nativo; não há build de desenvolvimento web), e é o caminho menos exercitado. Escreva o conjunto escolhido em cada caso de avaliação em runtime.platforms e faça run_snapshots.py iterá-los.

Confirme como os subprocessos claude -p executam — uma vez, antes de começar. Pergunte com AskUserQuestion se eles podem executar com --dangerously-skip-permissions, então aplique a mesma resposta a cada subprocesso desta execução (nunca re-prompt no meio da execução):

• Pular permissões (recomendado) — passe --dangerously-skip-permissions. Cada subprocesso executa sem supervisão dentro de uma fixture descartável em /private/tmp/expo-skill-eval-* e pode escrever arquivos e executar comandos de configuração sem solicitação.
• Aceitar edições apenas — passe --permission-mode acceptEdits em vez disso. Bash/instalações são negadas automaticamente (sem TTY), então algumas avaliações podem produzir saída parcial.

Um claude -p simples sem nenhum sinalizador não pode escrever arquivos. Se a solicitação já declarar uma preferência ("pular permissões", "não usar o sinalizador perigoso"), pule a pergunta.

Confirme como entregar o visualizador de resultados — uma vez, antecipadamente. Publicar no claude.ai é voltado para o exterior, então nunca o faça no meio da execução de surpresa; pergunte no mesmo AskUserQuestion inicial (junto com o sinalizador de permissão):

• Apenas local (padrão) — generate_viewer.py escreve viewer.html e o abre no navegador local. Nada sai da máquina.
• Publicar um Artifact compartilhável — adicionalmente renderize o visualizador para um Artifact do claude.ai (uma página web privada por padrão que o usuário pode compartilhar com colegas de equipe) no final. Faça isso apenas se o usuário optar por aqui.

Se a solicitação já disser se deve compartilhar/publicar, pule a pergunta. Veja a seção Visualizador para a mecânica de publicação.

Esquema de caso de avaliação

Você gera os casos de avaliação da execução — um por prompt escolhido — e os escreve em <workspace>/iteration-N/evals.json (o visualizador os lê de lá). Cada caso