charliesbot/android-design-explore

Exploração visual de design

Siga a skill android-design para cada decisão de design: sua seção 0 responde, componentes, temas, layout e as perguntas da verificação de tela. Esta skill possui o fluxo de trabalho. Cada execução é uma tentativa única: brief enviada, uma proposta escrita, verificada, exibida e depois para. Celular, dobrável, tablet, desktop e telas de apps Wear OS estão no escopo; tiles Wear, mostradores de relógio e widgets não estão. Onde o Wear difere, a seção Wear OS abaixo diz como.

Uma proposta é um arquivo de dados que o aplicativo de visualização, uma janela nativa do macOS, desenha com componentes reais do Compose Material 3 e redesenha a cada salvamento. Você a verifica através da árvore de layout do aplicativo; o usuário julga o gosto na janela.

Requisitos

macOS, com o aplicativo de visualização instalado e registrado como um servidor MCP chamado android_design_preview. Chame sua ferramenta status primeiro. Quando suas ferramentas estiverem indisponíveis, pare e diga ao usuário as duas etapas, depois aguarde:

1. Construa e instale o aplicativo a partir de um checkout do repositório android-design: cd app && ./gradlew :app:installApp, que instala ~/Applications/AndroidDesignPreview.app.
2. Registre-o para sua ferramenta e reinicie a sessão (<binary> é ~/Applications/AndroidDesignPreview.app/Contents/MacOS/AndroidDesignPreview, escrito como caminho absoluto onde a ferramenta não expande ~):
   • Claude Code: claude mcp add --scope user android_design_preview -- <binary>
   • Codex: uma tabela [mcp_servers.android_design_preview] em ~/.codex/config.toml com command = "<binary>" e default_tools_approval_mode = "approve"
   • Antigravity: agy mcp add android_design_preview <binary>

Brief

Quando houver um app, leia suas telas relevantes, tema, assets e qualquer DESIGN.md e design/ propostas existentes primeiro. Responda a seção 0 de android-design na resposta.

• Escolha uma semente: a cor da marca, ou uma cor de conteúdo do assunto (um prato, um álbum, uma viagem), nunca o padrão do app #6750A4.
• Quando a tela for um momento herói (pergunta 3 da seção 0), aplique três ou mais táticas (seção 3) e nomeie-as.
• Mantenha o código do app e dependências inalterados.
• Use dados e assets representativos e não sensíveis. Use geração de imagem apenas para assets dentro de uma proposta, nunca como substituto para uma.

Faça várias propostas apenas quando o usuário pedir. Cada uma é seu próprio arquivo, uma composição distinta (não uma recoloração) com sua própria semente em seu theme, e pelo menos uma é herói.

Arquivos

Trabalhe na raiz do repositório do app, ou na pasta que o usuário nomear. Nunca escreva dentro do próprio repositório desta skill.

• DESIGN.md na raiz contém o sistema de design compartilhado. Crie-o quando faltar, com a semente escolhida, fontes e estilos nomeados. Altere-o apenas quando a direção mudar o que toda proposta compartilha; a aparência de uma direção vai no theme de sua proposta.
• design/<slug>.proposal.json contém uma proposta.

Ambos são arquivos rastreados comuns; commitá-los segue o fluxo de trabalho do próprio projeto. Diga ao usuário o caminho absoluto da proposta.

Escrever

1. Chame get_catalog (sua descrição de ferramenta diz o que retorna). É o único vocabulário de componentes: um componente que falta está fora de alcance, então construa a ideia a partir de Box, Row, Column, Text e Shape, ou deixe-o de fora.
2. Leia references/proposal-format.md, depois escreva DESIGN.md e a proposta, de forma compacta como sua seção "Escrevendo de forma compacta" diz.

A proposta carrega estas regras de design; proposal-format.md fornece a sintaxe para cada uma, e sua seção Regras de componentes contém as regras para abas, carrosséis, sobreposições, escolhas, barras de ferramentas, menus, barras de app e badges:

• A tela tem uma ação primária, marcada como primária, e ela lidera suas pares como a seção 2 de android-design descreve.
• Ela se adapta em 600 e 840 dp: uma barra de navegação em compacto se torna uma gaveta de médio para cima, e a tela de detalhes de uma lista abre ao lado da lista em larguras expandidas.
• Texto trunca propositalmente, com reticências. Rótulos de botão, chip e navegação cabem em uma linha.

Verificar

Para uma proposta, esta etapa substitui a renderização na verificação de tela de android-design. Responda suas perguntas a partir dos resumos de layout e erros de check_proposal (e get_tree quando não forem suficientes), nunca a partir de uma renderização ou pixels. Capturas de tela ficam fora deste loop: nunca tire ou peça uma.

1. Chame open_proposal com o caminho absoluto da proposta. Ele carrega o arquivo, monitora-o, mostra a janela e retorna erros de validação. Corrija-os e chame status até que relate nenhum.
2. Chame check_proposal. Uma chamada verifica cada tela em cada visão e retorna os erros de cada visão e o resumo layout; sua descrição de ferramenta fornece o formato.
3. Corrija cada erro uma vez, depois chame check_proposal novamente. Um erro overflow nomeia um nó disposto mais largo que seu pai ou a visão (uma linha que precisa de mais largura que sua célula); estreite-o, envolva-o ou deixe-o rolar. Reporte qualquer coisa ainda falhando em vez de entrar em loop.
4. Confirme a adaptação a partir dos resumos layout: cada visão maior revela o que sua resposta de adaptação da seção 0 prometeu, como um segundo painel, uma gaveta ou mais regiões. Google: "Espaço adicional não significa apenas tornar a mesma coisa maior." Uma visão maior com apenas as regiões do telefone espalhadas falha.
5. Chame get_tree apenas quando um resumo ou um erro não for suficiente; sua descrição de ferramenta diz o que retorna.

A etapa está concluída quando check_proposal passa ou cada erro restante está na lista que você reporta, e a adaptação está confirmada.

Mostrar

Chame show_preview. Diga em uma linha o que a proposta é, nomeie as táticas que um herói aplica, liste quaisquer descobertas não resolvidas e reporte "qualidade visual julgada apenas a partir da árvore de layout". Então pare e aguarde a resposta do usuário.

Revisar

Edite a mesma proposta com o feedback do usuário; a janela redesenha ao salvar. Repita a verificação nas telas que você alterou. A revisão substitui a versão antiga; não mantenha cópias.

Aprovar e portar

Aprovação é o usuário dizendo isso no chat. Reporte o caminho da proposta aprovada e que references/compose-mapping.md é a tabela de portabilidade. Um pedido apenas de exploração termina aí: não implemente. Um pedido de construção (a skill android-design envia construções focadas em design de novos apps, telas e redesenhos aqui primeiro) continua para a portabilidade. A aprovação nunca autoriza mudanças de versão de bibliotecas.

A portabilidade segue as regras de planejamento, branch, verificação e revisão do projeto solicitante:

1. Chame export_kotlin para as telas a portar. Seu Kotlin é o primeiro rascunho, não código finalizado.
2. Adapte-o às convenções do app e versões de bibliotecas com references/compose-mapping.md.
3. Renderize o resultado com a skill compose-preview e compare-o com as árvores da proposta nas mesmas visões.

Reporte componentes que o mapeamento marca como não verificados, e qualquer coisa que falte, em vez de inventar um equivalente Compose. Se o design não puder ser preservado com as dependências do app, pergunte.

Wear OS

Uma proposta Wear segue o mesmo fluxo de trabalho. android-design references/wear-os.md possui as regras de design, e proposal-format.md possui o formato do arquivo (id do catálogo, visões, Screen, primary, large).

• Seu próprio arquivo. Uma superfície por proposta: escreva design/<slug>-wear.proposal.json ao lado da do telefone.
• Verificação de adaptação: a substituição de tamanho Wear se aplica a partir de 225dp, então a verificação é "cabe e lê em ambos os tamanhos de relógio, e o maior mostra mais valor, nunca menos".
• DESIGN.md compartilhado: sua semente e papéis de cor se aplicam ao Wear; sua tipografia é substituída por Roboto Flex.
• Descobertas: corrija round-edge-clipped (controle ou texto cortado pela borda redonda em uma tela fixa) com margens percentuais ou um layout menor.
• Portar: as mesmas três etapas. export_kotlin escreve Compose para Wear: um WearAppTheme com as cores exatas do previewer, AppScaffold e ScreenScaffold, e Navigation 3 com deslizar para dispensar. Renderize a porta em ambos os tamanhos redondos (204 e 227dp).

Deletar

Quando o usuário pedir, remova design/<slug>.proposal.json. Mantenha DESIGN.md a menos que o usuário peça para removê-lo também.