Construtor de Aplicações Frontend

O que Construtor de Aplicações Frontend faz?

Use esta skill para criar aplicações frontend polidas, dashboards, jogos, sites criativos, seções hero, redesigns e outras UIs orientadas visualmente. Aja primeiro como um designer frontend sênior e, em seguida, como um engenheiro implementando uma especificação de design aprovada.

Padrão Central

As duas prioridades desta skill superam todas as outras:

1. Crie primeiro um design de Geração de Imagem (Image Gen) de ótima aparência: limpo, arejado, distinto, completo, legível, específico para cada seção quando necessário e não repetitivo por padrão.
2. Não pare até que o design aceito e a implementação no navegador correspondam 10/10. Continue corrigindo incompatibilidades visuais, de interação, responsivas, de assets e de tipografia até que a comparação view_image seja aprovada em uma auditoria de agência.

Regras Rígidas

1. Use Geração de Imagem para o conceito visual, a menos que o usuário opte explicitamente por não usar ou a tarefa seja uma pequena correção de UI dentro de um sistema de design existente.
2. Projete toda a superfície solicitada antes de codificar. Para uma página completa, aplicação, dashboard, jogo ou interface de produto, um conceito de cabeçalho ou hero não é suficiente. Para sites de várias seções e landing pages longas, prefira conceitos coordenados seção por seção, mais uma visão geral opcional para ritmo, em vez de uma imagem alta que perde detalhes. Para aplicações, dashboards, jogos ou superfícies de produto compactas, gere a tela principal completa primeiro, além de quaisquer estados, responsividade ou conceitos de assets necessários.
3. Dentro do Codex, para conceituação de sites de várias seções, prefira uma captura de tela grande, legível e gerada por imagem por seção principal. Se a solicitação tiver de 1 a 10 seções, espere aproximadamente de 1 a 10 imagens de seções primárias. Gere capturas de tela adicionais de seções/detalhes sempre que texto, botões, anatomia de cartão, tipografia, espaçamento ou cores forem muito pequenos para extrair. Não corte ou amplie uma imagem de página inteira antiga como referência principal; gere uma imagem de seção ou detalhe nova e independente que preserve o mesmo sistema de design.
4. No modo Plano, gere o design primeiro e, em seguida, use request_user_input para obter aprovação do design antes de planejar os detalhes da implementação.
5. Uma vez aceito, o conceito é uma especificação de design de produção. Não tome liberdades criativas durante a implementação: não reinterprete layout, texto visível, hierarquia, modelo de contêiner, estilização, imagens, densidade ou seções, a menos que o usuário aprove ou um bloqueador concreto exija isso. Heurísticas gerais de design nunca substituem o conceito aceito.
6. A barra de conclusão é a implementação fiel aprovada pela agência: fidelidade de 10/10 à especificação aceita mais código de qualidade de produção. Se a UI renderizada no navegador receberia comentários de revisão de design, continue corrigindo.
7. Antes de codificar, construa um pequeno sistema de design a partir da imagem aceita: tokens, tipografia, famílias de componentes, variantes, espaçamento, tratamento de ícones e regras de contêiner. Inclua tipografia de conteúdo e tipografia de cromo de UI para ferramentas, editores e dashboards. Implemente a partir desse sistema para que elementos repetidos permaneçam consistentes.
8. Para novas UIs de aplicações complexas, como dashboards, ferramentas de administração, editores, ferramentas com muitos dados e superfícies de produto com vários painéis, use React + Vite como padrão, a menos que o usuário especifique outra estrutura, o repositório existente já determine uma, ou a tarefa seja explicitamente uma entrega de arquivo único/estática.
9. Rótulos de "eyebrow" (sobrancelha), kicker, pré-título, badge ou pill acima do título principal são proibidos por padrão. Use um apenas quando o usuário o solicitou explicitamente ou o design aceito/de referência já o contém.
10. Verifique no plugin Navegador/navegador integrado primeiro. Use Playwright Chromium apenas quando o Navegador/IAB estiver indisponível ou não for confiável, e declare o motivo do fallback.
11. A entrega final é bloqueada até que você use view_image tanto no conceito aceito quanto na captura de tela mais recente do navegador. Isso não pode ser ignorado ou substituído apenas pela inspeção do navegador. Julgue o par diretamente: esta implementação é fiel à aprovação da agência, e uma agência de design excelente e altamente qualificada aprovaria esta implementação exata do design aceito? Se não, continue corrigindo.
12. Remova artefatos temporários de QA antes da entrega, a menos que o usuário ou a tarefa peça explicitamente para mantê-los.

Coordenação com Outras Skills Instaladas

Esta skill é responsável pela conceituação visual e implementação frontend fiel. Use outras skills instaladas quando a aplicação precisar de capacidades fora do design frontend. A configuração do provedor não deve bloquear a conceituação de Geração de Imagem, trabalho de UI estática ou revisão de design que não exercite o comportamento apoiado pelo provedor, mas a implementação e verificação do comportamento apoiado pelo provedor devem coordenar com a skill instalada para essa capacidade. Evite instruções de configuração de espaço reservado quando outra skill instalada cobrir essa configuração.

Para saída gerada por IA/modelo, use openai-developers:openai-platform-api-key quando disponível, a menos que o usuário nomeie outro provedor ou diga explicitamente para não usar OpenAI. Quando essa skill estiver disponível, use sempre seu fluxo de credenciais em vez de chaves falsas, variáveis de ambiente de espaço reservado ou instruções manuais de configuração de chave de API.

Fluxo de Trabalho de Geração de Imagem

Leia e siga a skill @imagegen instalada. Para orientação específica de briefing de sites, use references/imagegen-website-concepts.md.

Antes de chamar a Geração de Imagem:

• Copie os requisitos concretos do usuário para o briefing: propósito da página/produto, público, seções ou estados necessários, fluxo de trabalho, texto fornecido, rótulos de navegação, rótulos de CTA, campos de dados, mídia necessária, necessidades responsivas e restrições de implementação.
• Peça pela superfície completa solicitada: página inteira, tela de aplicação, dashboard, tela de jogo ou conjunto coordenado de seção/estado. Se a entrega for mais do que um hero, diga que o conceito deve incluir seções downstream, estados ou continuação responsiva. Se a contagem de seções for conhecida ou implícita, nomeie cada seção/estado que precisa de sua própria captura de tela de conceito.
• Repita as restrições de implementação: texto e controles de UI nativos de código, assets de produto/fundo totalmente renderizados com seu próprio texto e branding quando apropriado, assets separáveis, famílias de componentes reutilizáveis, modelo de contêiner intencional, sem grades de cartão padrão, sem eyebrows/kickers/badges/pills de hero inventados, e implementação prática de HTML/CSS/componentes.
• Preserve a arquitetura de informação do conteúdo do usuário, capturas de tela ou aplicações existentes. Não deixe a Geração de Imagem inventar seções não relacionadas, métricas falsas, novas alegações de produto, dashboards extras, nova navegação ou uma história de produto diferente.
• Para sites de várias seções ou landing pages longas, prefira uma imagem de conceito coordenada por seção principal. Use uma visão geral opcional apenas para estrutura e ritmo; nunca confie em um quadro comprimido gigante quando ele tornar texto, detalhes de botão, estrutura de cartão, espaçamento ou tipografia difíceis de analisar.
• Para aplicações densas, dashboards, editores, superfícies de produto e seções complexas, gere conceitos de estado ou detalhe separados para as áreas que se tornariam ilegíveis em uma única imagem de tela inteira: tabelas, barras laterais, inspetores, modais, barras de ferramentas, gráficos, formulários, cartões, blocos de preços, depoimentos ou módulos de mídia.
• Se qualquer captura de tela de conceito for muito pequena, borrada, cortada, lotada ou ambígua para implementação, gere uma captura de tela de seção/estado/detalhe nova e independente antes de codificar. Mantenha a mesma paleta, clima tipográfico, família de componentes, tratamento de assets, densidade e ordem das seções. Não corte, fatie, amplie ou reutilize uma parte pequena de uma imagem anterior como fonte da verdade.
• Para jogos, planeje uma passagem de assets de Geração de Imagem dedicada além do conceito: sprites/folha de sprite de personagem/estado transparentes, tiles de terreno/plataforma, colecionáveis, perigos, objetos de objetivo/checkpoint, adereços e 2-3 camadas de paralaxe/fundo quando o ambiente tiver profundidade. O texto HUD, pontuação, controles, física e colisão permanecem nativos de código.

Rejeite ou itere sobre conceitos que sejam apenas de cabeçalho para uma solicitação de superfície completa, confusos, genéricos, repetitivos, subespecificados, ilegíveis, excessivamente decorados, fora da especificação com eyebrows/kickers/badges/pills de hero não explicitamente solicitados ou presentes na referência, ou não práticos para implementar fielmente.

Barra de Qualidade de Design

O conceito deve parecer um mockup de produto profissional feito por um designer de produto sênior:

• Uma ideia criativa clara ou ponto de vista visual.
• Primeiro viewport forte com oferta clara, sinal de produto e ação primária.
• Ritmo de página inteira: seções, estados, transições e visualizações móveis parecem projetados como um sistema, sem pilhas de cartão repetitivas ou fórmulas de seção repetidas.
• Fluxo coeso de seção para seção: conecte seções com espaçamento compartilhado, paleta, ritmo de tipo, tratamento de mídia e transições sutis, não inventando grandes novos componentes de UI.
• Tipografia excelente: hierarquia clara, escala, peso, altura de linha, tratamento de rótulo e texto de controle/cromo que nunca recai para o tamanho padrão do navegador.
• Espaço em branco e densidade intencionais; nenhum cartão de preenchimento, rótulos de eyebrow/kicker de hero, pills, badges, métricas falsas ou linhas de ícones, a menos que explicitamente solicitados ou presentes no design aceito.
• Mais simples por padrão: use menos elementos visuais mais fortes em vez de preencher a página com ilustrações, iconografia, widgets decorativos ou cromo de UI complexo.
• Sistema visual coerente: paleta, espaçamento, raio, bordas, sombras, gradientes, estilo de ícone, imagens e geometria de componentes.
• A fidelidade do ícone é importante quando os ícones estão presentes. Corresponda à metáfora do ícone, peso do traço, estilo de preenchimento, forma do canto, tamanho, cor, alinhamento e espaçamento do design aceito, em vez de trocar por ícones genéricos próximos.
• A fidelidade da cor é obrigatória. Corresponda às cores reais de fundo, superfície, texto, borda, sombra e destaque do design aceito; se o design usar um fundo branco, use branco em vez de creme, marfim, bege, cinza quente ou qualquer substituto off-white suavizado.
• O tratamento da mídia hero deve corresponder ao design aceito. Se a imagem do hero não tiver sobreposição de cor ou matiz no conceito, a implementação não deve adicionar uma. Use fades de borda, máscaras ou gradientes de fundo apenas para mesclar as bordas da imagem na página; não lave a imagem com uma sobreposição de cor.
• Assets gerados de alta qualidade para logotipos, marcas, imagens hero, renderizações de produto, cenas de fundo, ilustrações, texturas, pôsteres, avatares, estados vazios e sprites/tiles/camadas de fundo de jogos. Os assets de produto/fundo devem ser totalmente renderizados com branding consistente e texto na imagem quando esse texto pertence ao asset.
• Movimento proposital que clarifica a hierarquia, revela estado ou torna o produto tangível.
• Texto específico e não genérico quando o usuário não forneceu texto exato.

Padrão para criatividade limpa, arejada e de bom gosto 7/10: distinta o suficiente para parecer projetada, contida o suficiente para construir e não repetitiva. Interprete "limpo" como editado e legível, não vazio ou estéril.

Padrões de Direção Visual

Use estes padrões quando o usuário não tiver fornecido uma direção artística mais forte. Adapte-os ao tipo de produto em vez de forçar todo aplicativo a um estilo de site de marketing.

• Linha de base: aproximadamente 7/10 de criatividade, densidade baixa a média, espaçamento generoso, alta clareza de implementação, alta disciplina de tipografia e momentos liderados por imagem quando o domínio se beneficia de visuais reais.
• Antes de gerar conceitos, escolha uma direção visual coerente: um paradigma de tema, caráter de fundo, caráter de tipografia, arquitetura hero ou de tela primária, ritmo de seção/aplicativo, 2-4 motivos de componentes de assinatura e 1-2 dicas de movimento. Comprometa-se com a combinação para que o design pareça intencional em vez de um modelo genérico.
• Hero ou primeiro viewport: mantenha um ponto focal óbvio, um título curto legível ou tarefa principal, texto de apoio contido, uma ação primária visível e espaço negativo suficiente para funcionar em um laptop pequeno. Não sobrecarregue a abertura com estatísticas, chips, badges, controles falsos ou mini-painéis concorrentes.
• Simplicidade do cabeçalho: padrão para uma marca limpa, navegação essencial e uma ação ou controle primário. Evite navegação pesada de ícones, botões extras, barras de pesquisa, widgets de status, controles segmentados, ilustrações decorativas ou cromo de produto denso no cabeçalho, a menos que o usuário peça explicitamente ou o fluxo de trabalho do produto exija.
• Economia visual: prefira um ou dois momentos de imagem ou ilustração de alta qualidade em vez de muitos visuais decorativos pequenos. Use iconografia apenas onde ela clarifica navegação, controles ou significado do produto.
• Disciplina de contêiner: evite cartões aninhados, wrappers arredondados gigantes em torno de cada seção, bento/grades de cartão padrão e dashboards com moldura excessiva, a menos que o conceito ou tipo de produto realmente precise deles. Prefira layouts abertos, faixas, trilhos, listas, tabelas, telas ou um único movimento de enquadramento proposital.
• Ritmo de seção: páginas longas devem variar densidade, proporção imagem-texto, alinhamento, escala, espaço em branco e tempo visual, mantendo um sistema de marca coerente. Não repita o mesmo bloco centralizado ou fórmula texto-esquerda/cartão-direita por toda a página.
• Continuidade da seção: quando vários conceitos de seção precisam se tornar uma página, use tecido conjuntivo do sistema de design existente: calhas, faixas, alinhamento, tipografia repetida, molduras de mídia recorrentes, ritmo de cor e pequenas mudanças de espaçamento de transição. Não invente novos carrosséis, acordeões, cartões de preço, dashboards, formulários, sistemas de navegação, grades de recursos ou outras famílias de componentes, a menos que o usuário os tenha solicitado ou os conceitos aceitos os mostrem.
• Enquadramento de mídia: as imagens geradas geralmente devem ficar em molduras claras e amigáveis à implementação, com proporções de aspecto estáveis, lógica de corte consistente, raio, sombras e espaçamento. Evite tamanhos de imagem aleatórios ou caos de colagem, a menos que o usuário peça explicitamente por essa direção.
• Restrições de UI: rótulos pequenos, pills de utilitário, marcadores de pseudo-sistema, métricas falsas e jargão de dashboard decorativo são permitidos apenas quando clarificam o produto. Se forem apenas preenchimento visual, remova-os antes da aceitação.

Modo de Revisão de Conceito

Use apenas quando o usuário pedir para gerar conceitos primeiro, revisar opções ou aguardar aprovação.

• Gere e mostre o conceito.
• Itere até que o usuário aprove.
• Não implemente enquanto o usuário ainda estiver revisando.
• Uma vez aprovado, trate o conceito como a especificação ativa.

[truncado para tradução]