Lançamos oficialmente o Android Skills em abril, e a resposta superou todas as nossas expectativas. Neste post do blog, vou abordar algumas das críticas que recebemos, explicando a filosofia e a metodologia por trás do projeto. Espero que isso também ajude você a entender o que acontece nos bastidores quando você instala e usa skills, permitindo-lhe fazer um melhor uso de tokens e do seu tempo.
Por que há tão poucas skills oficiais?
Agora mesmo, consideramos novas skills apenas quando existe uma lacuna verificável no conhecimento dos modelos de estado-da-arte (SOTA). De forma simples: você não precisa ensinar ao modelo o que ele já sabe. (Embora existam algumas exceções - continue lendo!)
Lançamos cerca de 20 skills oficiais até agora, e elas intencionalmente visam áreas altamente específicas e em constante movimento que os modelos padrão ainda não estão totalmente fundamentados - coisas como AGP 9, Navigation 3, APIs avançadas da câmera e SQL do Perfetto.
E quanto às skills de núcleo mais gerais? Cada skill instalada injeta entre 100-200 tokens no contexto base de cada tarefa que você inicia. Se essa skill realmente se ativar, esse número pode saltar rapidamente para milhares. Em muitos casos, acumular skills básicas é tanto contraproducente quanto caro. Antes de instalar uma skill para escrever Kotlin básico ou Compose, considere se o seu modelo LLM escolhido realmente precisa disso, ou se ele já sabe bem sobre esses tópicos.
Avaliando skills
Antes do lançamento, cada skill é testada contra um conjunto abrangente de avaliações que provam que a skill entrega valor claro. Essas avaliações devem passar quando a skill está ativa e falhar caso contrário. As avaliações são para skills o que os testes de integração são para código.
timeout_s: 1200
repository:
url: [redacted - internal git repo]
working_dir: wear_compose_m3_empty_app
category_ids:
- wear
prompt: |-
Adicione um pager horizontal ao MainActivity.kt. Tenha três páginas no pager. Cada página deve conter
o texto "Página 1", "Página 2" e "Página 3" respectivamente no centro da tela.
commands:
build:
- ./gradlew assembleDebug
acceptance_criteria:
project_builds: true
llm_diff_judge:
- Deve usar `HorizontalPagerScaffold`.
- Cada página deve usar `AnimatedPage` para envolver um `ScreenScaffold`.Avaliação de exemplo que verifica a implementação correta de um pager horizontal em um aplicativo wear
No mínimo, testamos a skill no Android Studio usando o modelo Gemini Flash mais recente. Dependendo da skill, também garantimos compatibilidade com outros modelos como Gemini Pro e agentes como Antigravity, além de sistemas terceirizados.
Todas as avaliações são executadas com acesso à Knowledge Base, então se a informação está na documentação e os modelos decidirem procurar por ela, não publicamos uma skill para isso.
Usando o Android Knowledge Base (Android Studio ou Android CLI)
Se você desenvolve aplicativos Android, deve sempre usar o Android Knowledge Base para ter acesso à documentação oficial. Se usa o agente no Android Studio, ele já está disponível como uma ferramenta, mas se usa outro agente, instale Android CLI. Entre outras coisas, ela contém o comando docs, que dá ao seu agente acesso à documentação oficial do Android. Ter uma única ferramenta é muito mais eficiente do que instalar centenas de skills.
Se seu modelo está sendo excessivamente confiante e você deseja que ele consulte mais frequentemente a documentação oficial, uma maneira comum de motivá-lo é adicionar “Sempre consulte a documentação oficial do Android ao lidar com APIs do Android” ao seu arquivo AGENTS.md ou equivalente. Claro, você também pode forçar isso pedindo que o agente verifique a documentação diretamente em suas solicitações.
Por que os pull requests estão desabilitados?
Ao contrário de nossa estrutura de avaliação, que depende de infraestrutura interna que não pode ser aberta para fontes públicas, estamos incapazes de aceitar pull requests diretos para novas habilidades. Sem essa infraestrutura, não teríamos como reavaliar as alterações enviadas por meio de PRs. No entanto, monitoramos ativamente o feedback da comunidade. Se você deseja relatar um bug, sugerir uma otimização ou solicitar uma nova habilidade oficial, por favor, abra um problema!
Quando faz sentido usar habilidades básicas ou de núcleo?
Mesmo que modelos SOTA geralmente não precisem de habilidades básicas, existem algumas situações em que habilitar habilidades básicas ou construídas pela comunidade adiciona valor real. Por exemplo:
- Você está usando prompts vagos: Habilidades amplificam sua intenção. Se você der um prompt vago como “adicione animações a esta tela”, uma habilidade específica de composição pode inspirar o modelo, levando-o para APIs modernas ou padrões de teste por captura que ele poderia não ter considerado.
- Você deseja usar modelos menores e mais baratos: Modelos de fronteira são caros. Se você estiver transferindo tarefas rotineiras para modelos abertos e pequenos como o Gemma 4, habilidades básicas preenchem as lacunas de conhecimento que parâmetros menores podem deixar.
- Você está refatorando ou revisando código legado: Modelos são excelentes em gerar códigos funcionais. No entanto, ao editar antigos repositórios de código, eles geralmente priorizam manter consistência com os padrões legados circundantes sobre reescrever as coisas com precisão moderna. Um agente revisor especializado equipado com habilidades básicas pode ajudar a quebrar esse hábito.
- Você se desvia do normal: Modelos de LLM amam o padrão “way” da Google para arquitetura de aplicativos Android. Se sua equipe usa uma arquitetura personalizada e altamente customizada na camada visual, o modelo terá dificuldade em permanecer alinhado. Uma habilidade personalizada que descreve explicitamente sua arquitetura faz toda a diferença.
Onde posso encontrar habilidades básicas?
A comunidade Android tem suas costas cobertas. Chris Banes possui uma coleção abrangente de habilidades para Compose e Kotlin, Ivan Morgillo publicou uma habilidade que audita projetos Compose, e Jaewoong Eum criou duas sobre testes e performance.
Sempre baixe habilidades de fontes confiáveis! Eu pessoalmente não confiaria em repositórios contendo dúzias ou centenas de habilidades Android, pois provavelmente são geradas por IA e não testadas, podendo até conter instruções maliciosas ou tendenciosas. Também não instale habilidades gerais de engenharia de software sem pensar; muitas delas estão adaptadas para desenvolvimento web.
Meta: obsolescência
Livremente inspirado por Karpathy: as habilidades de hoje estarão nos modelos do futuro. À medida que os modelos SOTA continuam a melhorar, esperamos que as habilidades se tornem obsoletas, especialmente aquelas construídas em torno de novas APIs. Para determinar quando desativá-las, executamos nossos testes quando novos modelos são lançados. Se eles passarem, manteremos por alguns meses até a maioria dos usuários ter se transferido.