tmj-90/gerador-de-landing-pages

Gere landing pages de alta conversão

Entregue uma página real: componentes TSX funcionais, estrutura de copy real e performance medida. Combine com o framework, estilo e convenções de componentes existentes no repositório, usando apenas dependências que ele já possui: uma entrega nunca instala uma nova dependência (o gancho de segurança bloqueia). Um projeto novo sem pilha escolhida pode usar Next.js + Tailwind como padrão; em outros casos, se a página realmente precisar de uma dependência ausente, chame mark_ticket_blocked nomeando-a.

Metas (Core Web Vitals "bom", campo p75): LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Atenda também WCAG 2.2 AA: contraste de texto ≥ 4,5:1, anel de foco visível, inputs rotulados e página operável por teclado.

Framework de copy (escolha um por página)

Framework	Estrutura	Melhor para
PAS	Problema → Agite → Solução	Tráfego ciente do problema
AIDA	Atenção → Interesse → Desejo → Ação	Tráfego frio, nova categoria
BAB	Antes → Depois → Ponte	Ofertas de resultado/transformação

Templates e o FAQ de cinco objeções estão em references/copy-frameworks.md. A habilidade copywriting cobre a elaboração de headlines e CTAs.

Blueprint de seções

1. Hero: um headline de resultado (≤ ~10 palavras), um subhead de uma frase sobre como, um CTA principal e um sinal de prova (um número, logotipos ou uma classificação). Sem carrossel.
2. Problema: o custo do status quo, nas palavras do cliente.
3. Solução / benefícios: 3–6 benefícios, cada um com uma explicação de uma linha e um visual opcional.
4. Prova social: depoimentos com nome, cargo, empresa e resultado; logotipos.
5. Precificação (se aplicável): 2–4 níveis com o recomendado destacado.
6. FAQ: as cinco objeções. Use <details>/<summary> nativo ou um acordeão acessível. A marcação FAQPage é opcional, pois o Google não mostra mais resultados avançados de FAQ.
7. CTA do rodapé: repete a ação principal com o mínimo de atrito (ex: apenas e-mail).

Passos

1. Colete os inputs. Nome do produto, público, principal dor, principal resultado, CTA principal e seu destino, a prova disponível e a direção de estilo. Leia o ticket, BRAND.md/tokens e as páginas existentes primeiro. Quando não houver supervisão, não pare para perguntar: use o que existe e marque lacunas como [TODO: …] na copy. Nunca invente depoimentos, logotipos, contagens de clientes ou classificações.

2. Escolha o framework com base na fonte de tráfego e nível de conscientização. Escreva a copy antes do layout. Crie rascunhos de cinco headlines e mantenha a mais clara.

3. Construa as seções como componentes separados no diretório de componentes do repositório. Coloque a copy em props ou em um objeto de conteúdo, não espalhada pelo JSX. Mantenha a página principalmente renderizada no servidor, com componentes cliente apenas onde a interação precisar deles.

4. Metadados SEO. Defina um <title> único, uma meta description, uma canonical, tags Open Graph e Twitter, e um <h1>. No Next.js App Router, use a exportação metadata.

5. Performance.

   • Carregue a imagem do hero/LCP com eager usando fetchpriority="high". No Next.js 16+ use <Image preload> (ou loading="eager" + fetchPriority="high"); priority é a forma no Next.js ≤ 15, obsoleta na versão 16. Nunca carregue com lazy.
   • Carregue com lazy imagens abaixo da dobra.
   • Toda imagem recebe width/height explícitos e formatos AVIF/WebP.
   • Fontes usam font-display: swap (ou next/font) com apenas os pesos necessários.
   • Nenhum script de terceiros acima da dobra.

6. Formulário (captura de leads). Use inputs rotulados com o type e autocomplete corretos, validação inline e um resumo de erros que mantenha o que o usuário digitou. Mostre um estado de sucesso, desabilite o duplo envio e poste para o endpoint real mencionado no ticket.

7. Verifique. Execute e registre cada verificação:

   • o type check (npx --no -- tsc --noEmit, que falha em vez de baixar) e o lint do repositório;
   • o script de build do repositório (ex: npm run build);
   • um teste de componente que renderize a página e afirme o h1, o href do CTA principal e os estados de sucesso e erro do formulário;
   • Lighthouse (mobile) como verificação de laboratório, registrando LCP, CLS, TBT e a pontuação de acessibilidade, apenas se já estiver instalado (npx --no -- lighthouse);
   • uma verificação de viewport em 375 px, 768 px e 1440 px para overflow e para o CTA acima da dobra, através do executor de testes de navegador do repositório, se ele tiver um.

   Nunca instale ou baixe uma ferramenta para executar uma verificação. Nomeie qualquer verificação que você não pôde executar em sua evidência, em vez de afirmar que foi feita.

Concluído quando

• A página compila, passa no type check e nos testes de componente.
• O hero declara um resultado e o CTA principal está acima da dobra em 375 px e 1440 px (verificado por um teste de viewport, ou nomeado como não verificado).
• Onde Lighthouse ou axe estão disponíveis, a execução em laboratório mostra LCP ≤ 2,5 s e CLS ≤ 0,1 no mobile e nenhuma violação de acessibilidade automatizada; caso contrário, a evidência diz que estes não foram medidos.
• Nenhuma prova inventada. Toda lacuna é marcada como [TODO] e listada no relatório.

Anti-padrões

• Uma imagem do hero carregada com lazy, ou mudança de layout devido a mídia sem tamanho ou fontes tardias.
• Vários CTAs com peso igual, ou navegação completa do site em uma página de campanha paga.
• Lorem ipsum ou copy genérica de preenchimento deixada no build. O único placeholder permitido é uma lacuna explícita [TODO: …] que o relatório lista.
• Carrosséis e vídeo com reprodução automática no hero.