Deixe um app pronto para as lojas pelo seu agente de programação

Antes de começar

Você precisa do Claude Code e de uma conta na AppFoyer. O plano gratuito basta: crie uma. Não há chave para criar — o agente pede a sua aprovação no navegador na primeira vez que se conecta.

Não tem nenhum agente de programação? Seis campos no navegador dão as mesmas cinco páginas sem o plugin.

Não usa o Claude Code? O plugin precisa dele, mas as páginas de privacidade e de termos não: os editores delas no painel têm um prompt, preenchido com os dados do seu app, que você roda em qualquer assistente e cola de volta — impresso na íntegra no guia da política de privacidade e no guia dos termos.

Instalação

claude
/plugin marketplace add appfoyer/claude-plugin
/plugin install appfoyer@appfoyer

Não é preciso conta para começar: o agente lê o seu build, mostra o que encontrou e faz as perguntas dele na sua máquina, e só pede que você se conecte quando há algo para salvar. Na primeira vez que ele chama a AppFoyer, o seu navegador abre em uma página de aprovação: entre ou crie uma conta gratuita, confira o nome e para onde o navegador vai voltar, e aprove. O Claude Code guarda a conexão e a renova sozinho; nada é copiado, nada fica guardado no seu shell. Se o navegador não abrir, rode /mcp, escolha appfoyer e selecione Authenticate. No app de desktop do Claude Code, conecte uma vez desse jeito a partir de um terminal e depois abra uma nova sessão ali: uma sessão que já estava rodando não enxerga a nova conexão. Desconecte na página Agent do painel e a próxima chamada falha imediatamente. O Claude Code não atualiza sozinho um marketplace de terceiros: em /plugin → Marketplaces → appfoyer, escolha Enable auto-update para receber as novas versões.

Não tem navegador nessa máquina — um servidor remoto, um contêiner, uma execução automatizada? Use uma API key: crie uma em Agent → API key — for CI and headless use, instale o plugin como acima para ter o fluxo de trabalho e adicione o servidor mais uma vez com a chave no cabeçalho:

export APPFOYER_API_KEY=cpk_…
claude mcp add --transport http appfoyer-key https://app.appfoyer.com/mcp --header "Authorization: Bearer $APPFOYER_API_KEY"

O plugin lê a chave apenas dessa variável de ambiente — a skill nunca a vê, e ela só trafega no cabeçalho Authorization que o Claude Code preenche.

Outro cliente MCP — claude.ai, Claude Desktop, Cursor, VS Code — pode se conectar a https://app.appfoyer.com/mcp do mesmo jeito, com a mesma página de aprovação. Ele recebe as ferramentas; o fluxo de trabalho passo a passo que lê os seus arquivos de build vem com o plugin do Claude Code.

O que dizer

Rode estes comandos dentro do repositório do seu app, não em um diretório vazio:

Exemplos

Diga com as suas próprias palavras; estes são os casos que a skill trata.

Um app, primeira execução

> Make this app store-ready

• Lista o que encontrou nos arquivos de build — SDKs, permissões, bundle id —, cada item com arquivo e linha.
• Pergunta só o que não conseguiu encontrar: nome da empresa, e-mail de suporte, jurisdição, links das lojas. No máximo duas rodadas.
• Cria o app, envia o ícone a partir do repositório e rascunha as cinco páginas.
• Termina com um link de revisão. Nada fica público até você publicar ali.

Rodar de novo depois de uma mudança

> Make this app store-ready

• Encontra o app existente pelo application id e compara os fatos novos com os armazenados.
• Reescreve só as páginas afetadas pela mudança, como a de privacidade depois de um novo SDK de analytics.
• Não mexe no ícone nem no endereço, a menos que você peça.

Vários flavors, nomeados no prompt

> Make com.acme.weather.free and com.acme.weather.pro store-ready

• Cria dois apps e não pergunta nada sobre a seleção.
• Lê a pasta, o nome e as dependências de cada flavor. Um SDK de anúncios usado só pelo flavor free não entra na política de privacidade do flavor pro.
• Devolve um link de revisão e uma tabela de URLs do console para cada flavor.

Vários flavors, sem nomes

> Make this app store-ready

• Lista os flavors com os application ids, todos pré-selecionados, e você escolhe quais ganham um site.
• Build types como debug e staging aparecem como excluídos, não como opções.

Dimensões marca × ambiente

> Make every brand store-ready

• Lista combinações (brandAProd, brandBProd), não flavors isolados.
• Oferece só o ambiente de produção. dev e qa nunca vão para uma loja.
• Lê o nome do app do Gradle (resValue, manifestPlaceholders) ou de source sets movidos, quando o build o coloca ali.
• Se não conseguir saber se uma dimensão é de ambientes ou de marcas, ele pergunta.

Endereço personalizado (Pro e Advanced)

> Make this app store-ready

• Monta o endereço a partir do nome do app em inglês, por exemplo weather-now.
• Se esse estiver ocupado ou parecido demais com um nome de marca, tenta o próximo — weather-now-app, acme-weather —, no máximo cinco vezes, e depois pergunta a você.
• No plano gratuito, mantém o endereço app-… e diz que o personalizado vem com o Pro.
• O endereço app-… continua servindo o mesmo site.

Mudar um endereço que você já usa

> Change the address to weather-radar

• Pergunta primeiro. O endereço personalizado antigo é liberado na hora, e uma página da loja que ainda o cite para de funcionar.
• Só muda depois que você diz sim.

Atualizar o ícone

> Update the app icon

• Encontra o ícone do launcher: o ícone 512 do Play, a maior imagem mipmap ou a imagem de marketing do AppIcon do iOS — primeiro a do próprio flavor.
• Se ele passar de 512 KB, reduz uma cópia em uma pasta temporária. O seu repositório não é alterado.
• Diz qual arquivo enviou. Em um app publicado, o novo ícone entra no ar na hora.

Um app com anúncios

> Make this app store-ready. AdMob publisher id pub-0000000000000000

• Escreve o app-ads.txt a partir das linhas que você fornece. O publisher id não está no seu código, então ele nunca inventa um.
• Lembra você de definir o site como site do desenvolvedor na página da loja.
• A AdMob já verificou arquivos app-ads.txt nos nossos endereços; dê a ela até 24 horas para rastrear.

Manter as páginas em sincronia com o build

> Add the AppFoyer drift check

• Toda execução de “make this app store-ready” grava appfoyer.json na raiz do repositório: os SDKs, tipos de dados e permissões a partir dos quais as páginas foram escritas. Ele é gravado pelo mesmo scanner que a verificação roda, nunca à mão.
• Este prompt mostra um workflow do GitHub para o appfoyer/check-action gratuito e grava .github/workflows/appfoyer.yml quando você diz sim. Ele nunca sobrescreve um que você já tenha.
• A partir daí, cada pull request lista o que adicionou ou removeu desde que as páginas foram escritas, com arquivo e linha. Rodar o plugin de novo atualiza os rascunhos e o appfoyer.json.
• Nada é commitado por você. O guia sobre manter a sua política de privacidade em sincronia tem os detalhes e a configuração para outros sistemas de CI.

Verificar sem mudar nada

> Is this app store-ready?

• Roda o checklist para cada app correspondente e informa o que falta. Não grava nada.
• Um flavor que ainda não tem app aparece como faltando.

Colocar os links dentro do app

> Wire the store-ready links into the app

• Precisa de páginas publicadas.
• Propõe um diff para os links de privacidade e de suporte na sua tela de configurações ou nas suas strings. Só aplica quando você diz sim, e nunca faz commit.

O que sai da sua máquina

Só fatos derivados:

• o nome do app, a plataforma e o bundle id ou application id;
• os nomes dos SDKs e das permissões encontrados nos seus arquivos de build;
• as respostas que você confirma — nome da empresa, e-mail de suporte, jurisdição, URLs das lojas;
• o texto das páginas que o agente rascunha, que fica armazenado na sua conta como rascunho;
• o próprio ícone do app, enviado uma vez por um link de upload de uso único.

Nenhum outro arquivo, nunca código-fonte, nunca segredos ou chaves encontrados no repositório. O que o agente envia é o que uma política de privacidade precisa declarar de qualquer forma.

Um arquivo é gravado no seu repositório e fica lá: appfoyer.json, o registro de a partir de que as páginas foram escritas, criado pelo scanner que vem no plugin. Ele não é enviado a lugar nenhum. O agente nunca faz commit dele, nem de nada mais — quem faz é você.

O que o agente não pode fazer

Seja pela conexão no navegador, seja com uma API key, o plugin tem uma credencial de agente — então publicar simplesmente não está disponível para ele. Isso é imposto no servidor, não pedindo educadamente ao agente:

• Não existe ferramenta de publicação. O agente escreve rascunhos; as suas páginas publicadas não mudam.
• Duas coisas não têm rascunho: o ícone e o endereço personalizado. Em um app publicado, elas mudam o site no ar na hora, e o agente avisa quando as definiu. Ele não pode substituir um endereço personalizado que você já usa sem o seu sim.
• A rota REST que publica uma página recusa de cara as credenciais de agente — só sessão.
• Cada página continua passando, no momento da publicação, pela mesma triagem de conteúdo que uma edição feita à mão.
• Cada chamada do agente é registrada no log de auditoria da conta, com a conexão ou a chave que a fez.

Então o pior caso de uma conexão ou chave comprometida são rascunhos para descartar, um ícone errado ou um endereço novo — não uma página ficando pública em seu nome.

As ferramentas que ele recebe

O plugin se conecta a um endpoint MCP que expõe exatamente estas:

Quando algo dá errado

Uma coisa que isso não muda

Os rascunhos são modelos completados a partir do seu código, não aconselhamento jurídico. Um agente escrevê-los rapidamente não os torna verdadeiros — leia o que ele escreveu antes de publicar, principalmente a lista do que o seu app coleta. Quem a loja responsabiliza é você.

Dúvidas: support@appfoyer.com.