Aston1690/landing-page-skill

Construtor de Landing Page

Construa a página finalizada, não um prompt, wireframe, moodboard ou amostra parcial. Entregue código funcional respaldado por QA real no navegador. Qualidade premium significa decisões específicas da marca, excelente tipografia/composição/imagens, clareza de conversão, artesanato responsivo, movimento proposital, acessibilidade, desempenho e integridade factual.

Na invocação, leia metadata.version acima e registre landing-page v<versão> no briefing do projeto. Repita essa versão exata no relatório de conclusão para que cada página gerada permaneça rastreável até a versão do skill que a produziu.

Contrato de saída rigoroso

Entregue:

• uma implementação responsiva completa em um projeto novo ou explicitamente aprovado existente;
• cópia exata fornecida pelo usuário preservada textualmente; escreva, edite ou reestruture a cópia apenas quando o usuário solicitar explicitamente;
• um sistema de marca funcional, manifesto de ativos/notas de proveniência e notas de integração;
• imagens de produção em vez de placeholders quando a geração de imagens ou ativos aprovados estiverem disponíveis;
• coreografia GSAP proposital, movimento de seção acionado por scroll e micro-interações de controle por padrão para builds completos, sujeito às exceções de modo documentadas;
• metadados SEO/OG, estrutura semântica, estados de acessibilidade e mídia otimizada;
• viewport do usuário testado no navegador, limites de breakpoint, tablet, mobile estreito e estados mobile comuns;
• implantação na Vercel por padrão, seguida de verificação ao vivo em desktop/mobile; pergunte apenas quando a autenticação ou outro bloqueio real impedir a implantação.

Nunca invente alegações, métricas, credenciais, depoimentos, logotipos de clientes, texto regulamentado, produtos, capturas de tela, detalhes de contato ou sucesso de formulário.

Roteamento de skill obrigatório

Carregue antes de construir:

1. frontend-design para direção de arte específica da marca e tese visual.
2. design-taste-frontend para implementação anti-slop e pré-voo responsivo.
3. imagegen-frontend-web apenas quando a matriz de modo autoritativa resolver isso em: ambiguidade visual, direção liderada por imagem, conceitos solicitados ou ativos aprovados insuficientes.
4. Este skill landing-page para orquestração, construção, QA e entrega.
5. A capacidade de geração de imagens de produção disponível ou media-use quando o inventário de ativos oficial/fornecido não puder suportar a direção visual aprovada.
6. imagegen-frontend-mobile apenas para mídia conceitual de tela de aplicativo claramente rotulada ou conceitos de tela de produto aprovados em uma página de marketing de aplicativo móvel. Nunca use para projetar web móvel responsiva ou para sugerir que telas geradas são funcionalidades de produto verificadas.

Leia references/frontend-skill-stack.md para regras de conflito de pilha.

Decisão de modo de projeto

Leia references/policy-matrix.md. É a única fonte autoritativa para Imagegen, GSAP, preservação, aprovação, segurança de integração, cobertura de viewport e roteamento de gate de qualidade. Selecione exatamente um de seus seis modos e registre as decisões resolvidas mais a justificativa. Nenhuma prosa em outro lugar pode substituir a matriz.

Quando o usuário disser "do zero" ou "não toque em construções anteriores", crie um projeto com nome único e nunca edite trabalhos anteriores.

Fase 1: Coleta de informações na invocação

Faça uma pergunta curta de cada vez. Nunca combine vários campos em um parágrafo ou questionário. Aguarde a resposta antes de fazer a próxima pergunta realmente necessária.

Use esta ordem, pulando qualquer coisa já fornecida ou seguramente inferível:

1. Para qual empresa/produto e site oficial é isso?
2. Onde está a cópia final aprovada pelo usuário? A cópia é necessária e preservada exatamente.
3. Onde estão o guia de marca, logotipo e ativos aprovados, se existirem?
4. Esta é uma nova construção separada ou uma edição de projeto existente?
5. Pergunte sobre público, destino do CTA, integração ou conformidade apenas se o site/cópia fornecidos não responderem a isso e isso bloquear materialmente a implementação.

Não pergunte se a cópia pode ser reescrita. Não se ofereça para escrever ou alterar a cópia. Escrever, editar ou reestruturar é habilitado apenas por uma solicitação explícita do usuário. Não pergunte se deve implantar; a implantação na Vercel é o padrão.

Leia references/intake-brand-assets.md e siga sua hierarquia de fontes, recuperação de logotipo, fallback de guia de marca, conformidade, integração e regras de proveniência.

Fase 2: Evidência e auditoria de marca

Após a coleta:

1. Leia as instruções do projeto, briefing/conteúdo aprovado, aprovações anteriores e referências fornecidas.
2. Abra o site oficial em um navegador real quando existir; caso contrário, registre a condição de nova marca/sem site e continue a partir do contexto fornecido.
3. Extraia fontes/cores computadas, variantes de logotipo, espaçamento, grade, raios, botões, ícones, imagens, navegação, formulários, rodapé, comportamento responsivo e movimento.
4. Recupere e verifique visualmente um logotipo SVG oficial ou PNG transparente de alta resolução. Se um logotipo existente não estiver disponível, peça ao usuário por ele. Se nenhum logotipo existir, confirme se um tratamento de nome de produto de texto simples é aceitável e registre que o design do logotipo está fora do escopo. Nunca redesenhe ou gere um logotipo de cliente.
5. Extraia texto e imagens do documento juntos; preserve as relações imagem-cópia.
6. Crie um manifesto de ativos verificado.
7. Se nenhum guia de marca existir, crie um guia de projeto compacto de autoria do agente e rotule-o honestamente.

Para trabalho regulamentado/sensível à confiança, preserve isenções de responsabilidade, licenças, texto de premiação, elegibilidade, consentimento e qualificações fornecidos, a menos que as edições sejam explicitamente autorizadas.

Fase 3: Conteúdo e arquitetura de conversão

Crie um manifesto de conteúdo antes do design:

• título/corpo/CTA/afirmação com origem para cada seção;
• função da seção: atrair, explicar, provar, diferenciar, responder ou converter;
• fonte de evidência ou placeholder não resolvido;
• visual/mídia pretendida e status do ativo;
• caminho de conversão principal e destino do CTA.
• approval_status e verification_status rastreados separadamente para alegações factuais, depoimentos, métricas, credenciais e texto regulamentado.

A política de conteúdo padrão é a preservação exata da cópia fornecida pelo usuário. authorized_editing ou agent_draft_unapproved podem ser selecionados apenas quando o usuário solicitar explicitamente edição ou redação. Rascunhos de agente permanecem não aprovados e não podem conter alegações sem suporte.

Use apenas seções que respondam a uma pergunta real de conversão. Não inclua mecanicamente herói + confiança + três cartões + depoimentos + FAQ. Uma ideia principal por seção. Preserve a IA aprovada em projetos existentes, a menos que autorizado a alterá-la.

Fase 4: Briefing de design e Imagegen

Escreva o briefing pré-código:

• público, objetivo de conversão, fonte da verdade, modo de projeto;
• uma tese visual específica do assunto e espinha narrativa;
• paleta, funções tipográficas, grade/espaçamento, gramática de forma/componente;
• grau de imagem, mapa de ativos, plano de geração de imagens, elemento de assinatura;
• comportamento da primeira dobra e seções complexas em desktop/tablet/mobile;
• storyboard de movimento com um propósito para cada sequência;
• lista explícita de evitar e critérios de aceitação.

Rejeite a direção se puder ser reutilizada inalterada para uma marca não relacionada.

Quando a matriz de política resolver o Imagegen como ativado, leia references/imagegen-production.md:

1. Use imagegen-frontend-web e anuncie a contagem de referência selecionada.
2. Gere e inspecione uma referência horizontal separada para cada seção selecionada.
3. Mantenha um mundo de marca enquanto varia composição e densidade.
4. Trave a direção por meio de um checkpoint do usuário (troca solicitada/consequente) ou um gate de aceitação do agente (autônomo, reversível, com origem). Registre qual modo de aprovação foi usado.
5. Gere/resolva ativos de produção separadamente em proporções reais sem texto, logotipos, alegações ou marcas d'água incorporados. UI é excluída, exceto para o caso de tela conceitual de aplicativo claramente rotulado e roteado pela política.
6. Inspecione, corte, otimize, adicione texto alternativo e registre a proveniência.

Julgue as imagens por utilidade narrativa, repetição visível, especificidade da marca e qualidade do ativo, em vez de cotas. Uma página deliberadamente liderada por tipografia ou rica em ativos pode pular a geração com uma justificativa registrada; uma página acidentalmente pesada em texto ou genérica de estoque falha.

Fase 5: Implementação estática e aprovação

Escolha a pilha mais simples que atenda ao briefing:

• preserve a estrutura, estilo, roteamento, componentes, análise e pipeline de ativos de um repositório existente;
• use HTML semântico, CSS externo e JS externo para páginas genuinamente estáticas;
• use React/Vite/Next apenas quando a arquitetura existente, componentes reutilizáveis, integrações, estado ou interação complexa justificarem;
• verifique as dependências antes de importá-las.

Complete a página estática antes do movimento. Ela já deve ter:

• cópia correta, logotipo/ativos verificados, destinos reais de CTA;
• tokens coerentes e gramática de componentes;
• tipografia controlada e quebras de linha no viewport do usuário;
• variedade composicional suficiente para evitar repetição visível, sem cotas de layout numéricas;
• cortes de imagem intencionais e dimensões reservadas;
• navegação funcional, formulários/links, estados de foco e interação;
• refluxo responsivo deliberado em vez de empilhamento acidental;
• sem mídia quebrada, estouro, recorte, UI falsa, placeholders ou resquícios de fonte.

Faça QA com captura de tela e corrija a composição estática antes de iniciar o GSAP.

Fase 6: Passagem de produção GSAP

Leia references/gsap-motion.md para cada build completo e redesenho substancial; planeje o movimento no briefing e implemente-o após a QA da composição estática.

O movimento está ativado por padrão para builds completos sob a matriz de política. Entregue coreografia de herói, movimento de seção específico de conteúdo e feedback para controles interativos existentes. Adapte a intensidade à marca. Uma restrição estática/tempo de execução/preservação válida pode alterar isso; a ausência de uma solicitação de animação explícita não é motivo para pular. Registre observações de tempo de execução em QA/motion-review.md; capturas de tela sozinhas não podem passar na aceitação de movimento.

Mantenha o conteúdo crítico visível se os scripts falharem ou carregarem lentamente. Não use listeners de scroll da janela bruta. Verifique a animação em guia ativa porque guias em segundo plano limitam os temporizadores.

Fase 7: QA no navegador

Execute a página localmente e inspecione capturas de tela e estados reais:

• viewport real do usuário, cada limite de breakpoint de layout, um tablet, um mobile estreito e um mobile comum; 375px/390px são padrões, não requisitos universais;
• primeira dobra, várias seções no meio da página, CTA/rodapé final;
• estados de movimento ativo e em repouso mais movimento reduzido;
• menus, âncoras, formulários, accordions, abas, carrosséis e uso do teclado;
• famílias/pesos de fonte computados onde a tipografia importa;
• carregamento/dimensões naturais da imagem, corte, texto alternativo;
• estouro horizontal, recorte, erros de console/rede, riscos de CLS;
• destino do formulário/CTA e comportamento de sucesso/erro. Use endpoints de sandbox/teste e dados sintéticos. Nunca envie leads reais, registros de CRM, pagamentos, e-mails ou eventos de análise sem aprovação explícita.

Corrija defeitos antes da entrega. Uma build que passa não é QA de design.

Fase 8: Gate de qualidade premium

Leia references/premium-quality-gate.md e pontue com evidências:

1. Especificidade da marca
2. Conversão e narrativa
3. Tipografia
4. Composição e espaçamento
5. Imagens e direção de arte
6. Artesanato de componentes
7. Design responsivo
8. Movimento
9. Acessibilidade e integridade
10. Desempenho e prontidão para produção

Use verificações críticas binárias mais âncoras de 0/5/8/10 com evidências. Nenhuma categoria aplicável pode pontuar abaixo de 8/10; mire 9+ no geral. N/A é permitido apenas com justificativa por escrito, incluindo movimento em uma página deliberadamente estática. Cite captura de tela, DOM, auditoria ou evidência de teste para cada pontuação. Qualquer critério de rejeição crítico falha na página independentemente da média. Corrija a categoria aplicável mais fraca, reexecute as evidências e repontue.

Se o usuário chamar o trabalho de básico, genérico ou ruim, invalide a direção de arte atual. Pare de microajustes, identifique a causa sistêmica, redefina a tese/referência/primeira dobra, reconstrua e refaça a QA.

Fase 9: SEO, desempenho e implantação

Antes da entrega:

• um H1, estrutura de cabeçalho lógica, título, descrição, canônica, metadados OG e favicon;
• imagens responsivas otimizadas, prioridade/pré-carregamento de herói quando apropriado, mídia abaixo da dobra com carregamento preguiçoso;
• no máximo duas famílias de fonte justificadas e apenas os pesos necessários;
• elementos semânticos, rótulos, texto alternativo, contraste, foco, teclado e suporte a movimento reduzido;
• sem integrações falsas, alegações não verificadas, erros de console, links quebrados ou segredos não resolvidos;
• notas de origem com proveniência de cópia/ativos/logotipo/imagegen/integração.

Implante toda landing page concluída na Vercel por padrão usando a configuração Vercel existente do projeto ou um nome de projeto novo e isolado. Se autenticação, propriedade, segredos ou outro bloqueio real impedir a implantação, pergunte apenas sobre esse bloqueio. Verifique o alias ao vivo exato em um navegador real em desktop e mobile; verifique marcadores de título/conteúdo, ativos, navegação, formulários, estouro, console, movimento e propriedade do alias. Sucesso de CLI ou HTTP 200 sozinho não é prova.

Lista de rejeição anti-slop

Rejeite:

• gradientes genéricos roxos/azuis de IA, borrões, cartões de vidro sem sentido, enchimento 3D flutuante;
• apertos de mão de banco de imagens não relacionados, dashboards falsos, KPIs/gráficos inventados, prova social falsa;
• cabeçalhos superdimensionados ou condensados sem motivo de marca, texto corporal minúsculo, quebras estranhas;
• linhas idênticas de três cartões, famílias de layout repetidas, comprimidos/raios/sombras excessivos;
• cópia como "revolucionar", "desencadear", "próxima geração", "perfeitamente" ou rótulos de CTA vagos;
• palavras/logotipos/UI gerados dentro de imagens de produção;
• mobile que é meramente desktop empilhado verticalmente;
• animação usada para esconder design estático fraco;
• elementos decorativos cujo único trabalho é preencher espaço.

Prefira ativos de marca verificados, imagens específicas do assunto, tipografia controlada, composição variada, mas coerente, uma assinatura memorável, espaço negativo proposital, prova clara e um caminho de conversão decisivo.

Mapa de referências

Necessidade	Leia
Roteamento autoritativo de modo de projeto	references/policy-matrix.md
Coleta, site/marca/logotipo/conteúdo/ativos/integrações	references/intake-brand-assets.md
Roteamento/conflitos de pilha frontend	references/frontend-skill-stack.md
Regras de geração de imagens de produção	references/imagegen-production.md
Diretrizes de produção GSAP	references/gsap-motion.md
Gate de qualidade premium	references/premium-quality-gate.md
Matriz de política para decisões de modo	references/policy-matrix.md
Direção de arte e tese visual	references/frontend-design.md
Implementação anti-slop e pré-voo responsivo	references/design-taste-frontend.md
Regras de uso de mídia para ativos	references/media-use.md
Geração de imagens para web	references/imagegen-frontend-web.md
Geração de imagens para mobile	references/imagegen-frontend-mobile.md
Intake de ativos de marca	references/intake-brand-assets.md