Construtor de Aplicações Frontend

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

Padrão Principal

As duas prioridades desta skill superam todas as outras:

Crie primeiro um design de Image Gen com ótima aparência: limpo, arejado, distinto, completo, legível, específico por seção quando necessário e não repetitivo por padrão.
Não pare até que o design aceito e a implementação no navegador coincidam em 10/10. Continue corrigindo incompatibilidades visuais, de interação, responsivas, de assets e de tipografia até que uma comparação view_image passe na aprovação de uma agência.

Regras Rígidas

Use Image Gen para o conceito visual, a menos que o usuário opte explicitamente por não usá-lo ou que a tarefa seja uma pequena correção de UI dentro de um sistema de design existente.
Projete a superfície completa solicitada antes de codificar. Para uma página completa, aplicativo, dashboard, jogo ou interface de produto, um cabeçalho ou conceito de hero não é suficiente. Para sites com várias seções e landing pages longas, prefira conceitos coordenados seção por seção, além de uma visão geral opcional para ritmo, em vez de uma imagem alta que perde detalhes. Para aplicativos, dashboards, jogos ou superfícies de produto compactas, gere a tela principal completa mais quaisquer estados necessários, responsivos ou conceitos de assets primeiro.
Dentro do Codex, por padrão, conceitue sites com várias seções com uma captura de tela de Image Gen nova, grande e legível 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 principais. Gere capturas de tela adicionais de seções/detalhes sempre que texto, botões, anatomia de cards, tipografia, espaçamento ou cores forem muito pequenos para extrair. Não corte ou amplie uma imagem antiga de página inteira como referência principal; regenere uma nova imagem de seção ou detalhe independente que preserve o mesmo sistema de design.
No modo Planejar, gere o design primeiro, depois use request_user_input para obter aprovação do design antes de planejar os detalhes da implementação.
Uma vez aceito, o conceito é uma especificação de design de produção. Sem liberdades criativas durante a implementação: não reinterpretar layout, cópia visível, hierarquia, modelo de contêiner, estilo, imagens, densidade ou seções, a menos que o usuário aprove ou que um bloqueador concreto o exija. Heurísticas gerais de design nunca substituem o conceito aceito.
A barra de conclusão é a implementação fiel aprovada pela agência: fidelidade 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.
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.
Para UIs de aplicativos novos e complexos, como dashboards, ferramentas de administração, editores, ferramentas com muitos dados e superfícies de produto com vários painéis, use React + Vite por padrão, a menos que o usuário especifique outra estrutura, o repositório existente já dite uma ou a tarefa seja explicitamente um entregável de arquivo único/estático.
Eyebrow, kicker, pretitle, badge ou rótulos do tipo pill acima do título principal são proibidos por padrão. Use um apenas quando o usuário solicitar explicitamente ou o design aceito/de referência já o contiver.
Verifique primeiro no plugin de Navegador / navegador integrado. Use Playwright Chromium apenas quando o Navegador/IAB estiver indisponível ou não for confiável, e indique o motivo da alternativa.
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 no navegador. Julgue o par diretamente: esta implementação é fielmente aprovada por uma 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.
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 fiel de frontend. Use outras skills instaladas quando o aplicativo precisar de capacidades fora do design de frontend. A configuração do provedor não deve bloquear a conceituação com Image Gen, o trabalho de UI estática ou a 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 através da 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, sempre use 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 do Image Gen

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 o Image Gen:

Copie os requisitos concretos do usuário para o briefing: propósito do produto/página, público-alvo, seções ou estados necessários, fluxo de trabalho, cópia fornecida, rótulos de navegação, rótulos de CTA, campos de dados, mídia necessária, necessidades responsivas e restrições de implementação.
Pergunte pela superfície completa solicitada: página inteira, tela de aplicativo, dashboard, tela de jogo ou conjunto coordenado de seções/estados. Se o entregável for mais do que um hero, diga que o conceito deve incluir seções downstream, estados ou continuação responsiva. Se o número de seções for conhecido ou implícito, nomeie cada seção/estado que precisa de sua própria captura de tela conceitual.
Repita as restrições de implementação: texto e controles de UI de aplicativo nativos de código, assets de produto/fundo totalmente renderizados com seu próprio texto e marca quando apropriado, assets separáveis, famílias de componentes reutilizáveis, modelo de contêiner intencional, sem grades de card padrão, sem eyebrows/kickers/badges/pills de hero inventados e implementação prática de HTML/CSS/componentes.
Preserve a arquitetura da informação do conteúdo, capturas de tela ou aplicativos existentes do usuário. Não deixe o Image Gen 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 com várias seções ou landing pages longas, use por padrão 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 gigante comprimido quando isso dificultar a análise de texto, detalhes de botões, estrutura de cards, espaçamento ou tipografia.
Para aplicativos densos, 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 cheia: tabelas, barras laterais, inspetores, modais, barras de ferramentas, gráficos, formulários, cards, blocos de preços, depoimentos ou módulos de mídia.
Se qualquer captura de tela conceitual for muito pequena, borrada, cortada, cheia ou ambígua para implementação, gere uma nova captura de tela de seção/estado/detalhe independente antes de codificar. Mantenha a mesma paleta, humor tipográfico, família de componentes, tratamento de assets, densidade e ordem das seções. Não corte, fatie, amplie ou reuse uma parte minúscula de uma imagem anterior como fonte da verdade.
Para jogos, planeje uma passagem de assets Image Gen dedicada além do conceito: sprites/folhas de sprites de personagem/estado transparentes, tiles de terreno/plataforma, colecionáveis, perigos, objetos de objetivo/ponto de verificação, adereços e 2-3 camadas de parallax/fundo quando o ambiente tiver profundidade. Texto de HUD, pontuação, controles, física e colisão permanecem nativos de código.

Rejeite ou itere em conceitos que são 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 solicitados explicitamente ou presentes na referência, ou não práticos para implementar fielmente.

Padrão de Qualidade de Design

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

Uma ideia criativa clara ou ponto de vista visual.
Viewport inicial 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 mobile parecem projetados como um sistema, sem pilhas repetitivas de cards ou fórmulas de seção repetidas.
Fluxo coeso de seção para seção: conecte seções com espaçamento compartilhado, paleta, ritmo tipográfico, tratamento de mídia e transições sutis, não inventando novos componentes de UI importantes.
Excelente tipografia: hierarquia clara, escala, peso, altura de linha, tratamento de rótulos e texto de controle/cromo que nunca recorre ao dimensionamento padrão do navegador.
Espaço em branco e densidade intencionais; sem cards 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 e 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 componente.
Fidelidade de ícone é importante quando ícones estão presentes. Corresponda à metáfora do ícone do design aceito, peso do traço, estilo de preenchimento, formato do canto, tamanho, cor, alinhamento e espaçamento, em vez de trocar por ícones genéricos próximos.
Fidelidade de 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 de off-white suavizado.
O tratamento de mídia do 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 de hero, renderizações de produtos, cenas de fundo, ilustrações, texturas, pôsteres, avatares, estados vazios e sprites/tiles/camadas de fundo de jogo. Assets de produto/fundo devem ser totalmente renderizados com marca consistente e texto na imagem quando esse texto pertence ao asset.
Movimento proposital que esclarece hierarquia, revela estado ou torna o produto tangível.
Cópia específica e não genérica quando o usuário não forneceu cópia exata.

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 de arte mais forte. Adapte-os ao tipo de produto em vez de forçar cada aplicativo a um estilo de site de marketing.

Linha de base: aproximadamente criatividade 7/10, 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, personagem de fundo, personagem tipográfico, arquitetura de hero ou tela principal, ritmo de seção/aplicativo, 2-4 motivos de componente 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 e legível ou tarefa principal, cópia de apoio contida, uma ação primária visível e espaço negativo suficiente para funcionar em um laptop pequeno. Não superlotar a visualização de abertura com estatísticas, chips, badges, controles falsos ou mini-painéis concorrentes.
Simplicidade do cabeçalho: use por padrão uma marca limpa, navegação essencial e uma ação ou controle primário. Evite navegação pesada em í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 solicite explicitamente ou o fluxo de trabalho do produto os 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 esclarece navegação, controles ou significado do produto.
Disciplina de contêiner: evite cards aninhados, wrappers arredondados gigantes em torno de cada seção, grades padrão de bento/cards e dashboards excessivamente emoldurados, a menos que o conceito ou tipo de produto realmente precise deles. Prefira layouts abertos, bandas, trilhas, 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/card à direita em toda a página.
Continuidade de seção: quando vários conceitos de seção precisam se tornar uma página, use tecido conjuntivo do sistema de design existente: calhas, bandas, 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, cards 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 devem geralmente 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 utilidade, marcadores de pseudo-sistema, métricas falsas e jargão de dashboard decorativo são permitidos apenas quando esclarecem 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 esperar pela aprovação.

Gere e mostre o conceito.
Itere até que o usuário aprove.
Não implemente até que o design seja aceito.

Modo de Implementação

Use assim que um design de conceito for aceito ou quando uma especificação de design existente for fornecida.

Extraia o sistema de design: tokens, tipografia, componentes, variantes, espaçamento, tratamento de ícones e regras de contêiner.
Implemente usando a estrutura mais adequada (por exemplo, React + Vite para dashboards, HTML estático para sites simples).
Construa o layout para corresponder ao conceito pixel por pixel, usando o sistema de design extraído.
Verifique a fidelidade comparando view_image do conceito com a saída renderizada no navegador.
Ajuste até que a correspondência seja 10/10.

Verificação de Navegador

Use a visualização integrada do navegador ou o plugin de Navegador para verificações rápidas.
Use Playwright com Chromium apenas quando as ferramentas de navegador padrão não estiverem disponíveis.
Sempre valide com view_image antes da entrega final.

Entrega

Confirme a fidelidade do design.
Forneça código de produção com assets otimizados.
Remova marcadores de QA e comentários.
Forneça um resumo das decisões de implementação, se necessário.

Exemplos

"Crie uma landing page moderna e limpa para um aplicativo SaaS."
"Redesenhe este dashboard para ser mais arejado e legível."
"Construa um jogo simples com assets gerados por IA."
"Atualize a seção hero do nosso site para corresponder a este conceito."

Geruyang/agent-skills-library

O que é agent-skills-library?

Perguntar na sua IA favorita

Documentação