Interface Forge
Transforme a intenção do produto em uma interface reconhecível, usável e implementável. Combine direção de arte, repertório consultável e implementação de front-end para web, iOS e Android. Responda no idioma do usuário; preserve a linguagem do produto e as convenções do repositório.
Resolva a plataforma e a stack
Identifique os destinos pedidos e a tecnologia real antes de escolher componentes ou testes. Inspecione os manifests e a implementação: projetos Swift/Xcode para SwiftUI ou UIKit; Gradle e AndroidManifest para Compose ou Views; package.json e configuração nativa para React Native/Expo; pubspec.yaml para Flutter. React com DOM, React Native e uma aplicação em WebView têm mecanismos diferentes.
Preserve a stack existente e confira versões mínimas de sistema, bibliotecas e dispositivos-alvo quando afetarem a decisão. Em projeto novo, pergunte sobre plataforma ou tecnologia apenas se a escolha não puder ser inferida e alterar materialmente o trabalho. Não substitua um pedido de app por uma página responsiva.
Para destino único, leia o guia da plataforma correspondente, além dos módulos pertinentes à tarefa. Para app compartilhado iOS/Android, leia também o guia multiplataforma e as diferenças relevantes dos dois destinos. A marca pode ser comum; navegação, controles, gestos, acessibilidade e relação com o sistema precisam funcionar em cada plataforma.
Comece pelo trabalho solicitado
Identifique a superfície, a tarefa principal de quem a usa e o alcance da mudança. Inspecione implementação, tokens, componentes e documentação existentes; veja a interface renderizada quando houver acesso. A ausência de DESIGN.md não significa ausência de identidade.
- Criar: estabeleça uma direção para a nova superfície. Uma página nova em produto existente normalmente herda seu sistema.
- Redesenhar: mude a linguagem visual dentro do escopo pedido, preservando fatos, funções e restrições do produto.
- Refinar: melhore o alvo mantendo sua identidade e seu comportamento. Um ajuste de botão não precisa de um novo sistema.
- Revisar: entregue diagnóstico com evidências; implemente correções quando o pedido também as autorizar.
Resolva detalhes reversíveis com as evidências disponíveis. Pergunte apenas quando a informação mudar materialmente o resultado: público desconhecido com implicações reais, fluxo ambíguo ou falta de acesso a uma referência essencial. Enquanto isso, avance no que estiver definido. Não transforme um pedido executável em um menu obrigatório.
Defina o resultado para o visitante
Escolha pelo objetivo desta superfície, não pelo setor da empresa:
| Objetivo | Prioridade de design | Evidência de sucesso |
|---|---|---|
| Decidir ou contratar | Proposta concreta, demonstração e próxima ação | A pessoa entende a oferta e encontra a ação relevante |
| Executar uma tarefa | Hierarquia, estados, densidade e previsibilidade | O fluxo principal funciona com pouco esforço |
| Ler ou aprender | Organização, navegação e conforto de leitura | A informação é compreensível e encontrável |
| Explorar uma obra | Conteúdo, enquadramento e expressão | O trabalho aparece com destaque e permanece acessível |
Uma ferramenta pode ter uma landing page expressiva e uma tela de operação discreta. Não force a mesma composição nas duas. No app, o objetivo da tela também não elimina as expectativas de navegação e interação da plataforma.
Carregue apenas o que a tarefa precisa
| Necessidade | Referência |
|---|---|
| Direção visual, referência externa ou evitar aparência genérica | direcao-visual.md |
| Repertório de estilos, fontes, paletas, padrões e gráficos | repertorio.md |
| Tokens, componentes e consistência entre páginas | sistema-design.md |
| HTML/CSS, compatibilidade, responsividade ou desempenho visual | web-plataforma.md |
| App iOS/iPadOS, SwiftUI, UIKit ou comportamento Apple | ios.md |
| App Android, Compose, Views ou comportamento Material | android.md |
| React Native/Expo, Flutter, WebView ou adaptação entre plataformas | multiplataforma.md |
| Formulários, estados, acessibilidade, conteúdo e interação | interacao-acessibilidade.md |
| Crítica, auditoria, polimento e verificação final | revisao.md |
| Redesign/restyle preservando comportamento e comparando antes/depois | redesign-preservacao.md |
| Verificação em Simulator, emulador ou aparelho e auditoria nativa | revisao-nativa.md |
| Motion design, storyboard, demonstração e vídeo de produto | motion-produto.md |
| Experiência 3D interativa, câmera, luz, materiais e Three.js | tres-d.md |
| Bloom, profundidade de campo e pós-processamento em React Three Fiber | pos-processamento.md |
| Produzir ou preparar assets com Blender por CLI ou conector disponível | blender-assets.md |
| Pixel art, partículas, animação de sprites e sprite sheets | pixel-art.md |
| Descobrir bibliotecas e consultar coleções externas de estilos e prompts | referencias-audiovisuais.md |
As referências são módulos opcionais, não etapas a cumprir em todo pedido. Os caminhos partem da pasta desta skill. Sua execução básica não depende de outras skills, de uma CLI externa ou de rede.
Motion, 3D e audiovisual de produto
Escolha entre interação ao vivo, asset pré-renderizado e vídeo conforme o resultado pedido. Um vídeo de um botão funcionando não implementa o botão; uma página 3D não é um app nativo. Preserve um caminho acessível para a informação e a ação importantes, mesmo se um efeito falhar ou for reduzido.
O índice local de recursos pode ser consultado com search.py "<consulta>" --domain resource, pelo caminho absoluto desta skill. Ele informa encaixe, plataforma, dependências e limites de reaproveitamento. Os módulos fornecem direção e orientação de integração; não embutem Three.js, PixelFX, Blender, renderizador de vídeo ou todas as bibliotecas referenciadas.
Antes de implementar gráficos avançados, confira runtime, versões e orçamento de assets e renderização. Use as ferramentas realmente disponíveis; não instale conectores ou altere configurações globais apenas por consultar uma referência. Não importe regras de um runtime web para iOS/Android sem verificar suporte. Registre quando um recurso foi apenas consultado, implementado ou executado no destino.
Estabeleça uma direção antes de espalhar estilos
Para trabalho visual substancial, formule um contrato curto, na conversa ou no documento de design já adotado pelo projeto:
- tarefa e público; principal informação ou ação;
- direção visual concreta e sua relação com o conteúdo;
- composição, papéis tipográficos, cores semânticas e densidade;
- comportamento nas janelas e dispositivos-alvo, navegação e estados importantes;
- restrições e critério observável para considerar o resultado pronto.
Escolha uma direção com justificativa. Apresente alternativas quando o usuário pedir exploração ou quando uma decisão realmente depender de sua preferência. Não exija aprovação para cada decisão reversível.
O briefing explícito e a identidade aprovada prevalecem sobre gostos da skill. Gradientes, fontes de sistema, cards, cores saturadas e composições convencionais são recursos possíveis: escolha pelo propósito e pela execução. Evite repeti-los por automatismo.
Use repertório como hipótese
Quando faltar uma direção ou uma decisão específica, consulte o catálogo pelo mecanismo em repertorio.md. Compare resultados com o briefing e a interface existente; uma posição alta na busca não prova adequação, acessibilidade ou eficácia comercial.
Não carregue todos os CSVs no contexto. Não transforme recomendações de um setor em identidade obrigatória. Uma paleta pronta precisa de contraste verificado em seus usos reais; nomes de fontes não garantem licença, disponibilidade ou cobertura de idioma.
Implemente no sistema real
Use a stack e os componentes do projeto; não introduza framework ou biblioteca de animação por hábito. Para uma base nova sem stack definida, prefira a solução mais simples que satisfaça os destinos e a entrega, explicitando a escolha. Recursos HTML/CSS atendem à web ou à camada WebView; apps usam as APIs e unidades da implementação escolhida.
Construa primeiro uma fatia representativa do fluxo e sua adaptação ao menor espaço relevante. Em apps, inclua ida e volta da navegação, teclado e áreas seguras. Ajuste hierarquia, conteúdo e comportamento antes de propagar a linguagem para todas as telas. Reutilize tokens e componentes existentes; crie abstrações quando houver uma repetição ou uma responsabilidade concreta.
Conteúdo e estados fazem parte do design. Use os fatos fornecidos; identifique dados demonstrativos como tais. Não invente depoimentos, clientes, resultados, selos ou funcionalidades para preencher o layout. Use assets disponíveis ou ferramentas adequadas; se faltar um asset essencial, informe a dependência e entregue o restante implementável.
Verifique e conclua
Inspecione o resultado renderizado no destino quando as ferramentas permitirem: navegador para web; Simulator, emulador ou aparelho para app. Em uma mesma rodada, confira composição, fluxo, teclado, conteúdo longo e tamanhos relevantes. Corrija em lotes e verifique novamente as áreas afetadas. revisao.md orienta o diagnóstico comum; revisao-nativa.md orienta a evidência de apps.
Não confunda build aprovado com qualidade visual, screenshot com operação, scanner automático com conformidade ou preview web com validação iOS/Android. Diferencie observado, inferido e não verificado. Se o runtime ou SDK necessário estiver indisponível, faça a análise e implementação possíveis e relate o limite concreto. A validação existente do Compasso cobre web; a ampliação para apps exige seus próprios ensaios.
Finalize com o que mudou ou foi encontrado, a razão de design, os testes efetivamente feitos e as pendências relevantes. Em mudanças pequenas, poucas frases bastam. Não anuncie superioridade ou resultados de conversão sem evidência.