Quando Usar

• Use quando este fluxo de trabalho upstream corresponder ao objetivo declarado do usuário.
• Use quando a tarefa exigir os procedimentos documentados nesta habilidade.

EAS Simulator

Serviço EAS - custos aplicáveis. O EAS Simulator é um serviço EAS hospedado. O uso da sessão está sujeito aos preços e limites da sua conta. Veja https://expo.dev/pricing para os termos atuais.

O EAS Simulator executa um simulador iOS remoto ou emulador Android na infraestrutura EAS que você controla a partir da sua máquina — da CLI, de um agente de IA (via agent-device) e de uma pré-visualização no navegador. É a solução para ambientes que não podem executar um simulador localmente (máquinas Linux, agentes de nuvem/background como Cursor Cloud) e para permitir que um agente verifique uma alteração em um dispositivo real em vez de apenas raciocinar sobre o código.

Os comandos simulator:* são experimentais e ocultos, e exigem um eas-cli recente (≥ 20.3.0 no momento da escrita) — é por isso que esta habilidade executa tudo via npx --yes eas-cli@latest. Flags e verbos podem mudar; a saída --help do subcomando relevante é a autoritativa.

Quando Usar

O frontmatter description carrega as frases de gatilho. Em resumo: use isso para colocar o aplicativo de um usuário em um simulador na nuvem e interagir com ele — especialmente a partir de um agente sem Mac ou um agente de nuvem/sandbox. Não para sims locais (expo run:ios, Xcode, Android Studio), compilações/assinaturas para loja (isso é EAS Build), ou dispositivos físicos. Para o caso do macOS, veja Nuvem vs. local a seguir.

Nuvem vs. local: decida isso primeiro

• Solicitação explícita de nuvem/remoto/compartilhável: use o EAS Simulator após verificar o acesso, em qualquer host.
• Solicitação genérica de simulador: use um simulador local adequado quando disponível. Se o host não puder executar o simulador solicitado (por exemplo, iOS no Linux ou um sandbox na nuvem), use o EAS Simulator após verificar o acesso. Um host não-macOS ainda pode suportar um emulador Android local.
• Honre uma escolha local explícita; passe para expo run:ios / Xcode / Android Studio conforme apropriado. Esclareça apenas quando o ambiente solicitado permanecer ambíguo e afetar a tarefa.

Quando o usuário solicitar o EAS Simulator ou um simulador na nuvem, prossiga dentro dessa solicitação e qualquer orçamento declarado. Explique o uso aplicável uma vez e carregue a autorização existente durante a sessão. Pergunte antes de exceder um orçamento declarado ou expandir além do trabalho solicitado.

Pré-requisitos

• Execute cada comando eas via npx --yes eas-cli@latest … — garante uma CLI nova o suficiente para ter simulator:* (um eas global geralmente é muito antigo), e --yes pula a solicitação do npx. (Um eas simples é aceitável se eas --version estiver atualizado.)
• Autenticado. Máquina interativa → npx --yes eas-cli@latest login. Sandbox na nuvem / CI / agente headless não tem login no navegador — defina EXPO_TOKEN (expo.dev → Conta → Tokens de Acesso) no ambiente em vez disso. Verifique de qualquer forma com npx --yes eas-cli@latest whoami.
• Execute a partir de um diretório de projeto Expo. Um aplicativo novo precisa de configuração única: npx --yes eas-cli@latest init para criar/vincular o projeto (quando não há projectId), e defina ios.bundleIdentifier na configuração do aplicativo se estiver faltando — um create-expo-app novo geralmente não tem nenhum, e prebuild/eas build precisam dele (eles solicitam ou falham sem ele; por exemplo, dev.<owner>.<slug>). Leia a configuração atual com npx expo config --json (pode estar em app.config.js). A primeira execução do Modo C é lenta (compilação nativa); execuções posteriores a reutilizam.
• Um controlador para dirigir o dispositivo. Esta habilidade usa agent-device (código aberto, MIT), executado sob demanda via npx agent-device@latest — nada instalado globalmente. Appium e argent são interfaces de automação alternativas; web-preview-only não tem interface de automação. Veja [references/controllers.md].
• .env.eas-simulator é escrito/gerenciado pelo eas-cli (não por esta habilidade): ele contém o ID da sessão (EAS_SIMULATOR_SESSION_ID) + a URL/token do daemon, então get/stop/exec usam essa sessão por padrão (geralmente omita --id; passe --id <id> para direcionar outra). Ele carrega um token → mantenha-o ignorado no git (o eas-cli o marca como "não comitar", mas pode não adicionar a regra de ignore, e o .gitignore de um aplicativo novo não o cobrirá — adicione .env.eas-simulator se estiver faltando).
• Os blocos de comando assumem um shell POSIX (bash/zsh) — printf, lsof, $(seq …) loops não serão executados no cmd/PowerShell. No Windows, execute-os no WSL ou Git Bash, ou traduza conforme avança (as invocações eas-cli/agent-device em si são multiplataforma).

Ciclo de vida da sessão

…