🔀 O funil da trilha, convergindo num único build
Vale parar um segundo pra ver o caminho percorrido. No 5.1 você viu o problema: pedir "faz um site bonito" sem contexto sai genérico — um resultado de ~40% de qualidade. Do 5.2 ao 5.6 você foi fechando essa lacuna peça por peça: uma skill (conjunto de instruções fixas que ensina o processo de construir interface) de design global, o laço de screenshot (o agente construir → tirar print → comparar → ajustar, repetindo até bater com a referência), os limites desse laço (o que ele não enxerga sozinho), como usar uma referência visual sem copiar marca de terceiro, e uma pasta de marca permanente com cores, fontes e logo documentados.
Este módulo não ensina peça nova nenhuma — ele é o momento de usar as seis juntas, numa landing page real, do primeiro prompt até o link no ar. É por isso que ele é mais longo e mais prático que os anteriores: a teoria já foi dada, agora é construir.
Legenda: os cinco módulos práticos anteriores (mais o diagnóstico do 5.1) alimentam este build — cada seta é uma peça que você já tem pronta pra usar, não teoria nova.
💡 Conceito Principal
Este módulo não introduz técnica nova — ele orquestra as seis anteriores num único fluxo, do zero até o link publicado.
- •Se algum passo abaixo parecer estranho, é sinal pra voltar no módulo correspondente antes de continuar.
- •Não tem problema repetir uma etapa (por exemplo, rodar o laço de screenshot mais de uma vez) — build de verdade é iterativo.
🧩 Anatomia de uma landing page que funciona
Novo aqui? Uma landing page ("página de destino/pouso") é uma página web única, com um só objetivo: fazer o visitante entender rápido o que você oferece e tomar uma ação — comprar, se cadastrar, entrar em contato. É diferente de um site completo com várias páginas; a landing é enxuta, de propósito. Antes de construir, ajuda saber o que compõe uma landing eficaz, pra você reconhecer se o resultado do agente está no caminho certo ou só "bonito por fora".
A primeira dobra da tela — título forte, uma frase de apoio e o botão principal. Em 3 segundos o visitante precisa entender "o que é isto" e "o que eu ganho".
Uma seção logo abaixo mostrando 3 a 5 razões concretas pra confiar/comprar — não recursos técnicos, benefícios (o que muda pra quem usa).
CTA (do inglês call to action, "chamada pra ação") é o botão/link que leva o visitante a agir — "Comece agora", "Fale conosco". Uma landing boa repete o CTA principal em pelo menos 2 pontos da página (topo e fim).
Informação de contato/confiança (endereço, redes, ano) — pequeno, mas presente. Landing sem rodapé passa sensação de página inacabada.
✓ Landing que funciona
- ✓Um único objetivo claro por página — não tenta vender três coisas ao mesmo tempo
- ✓CTA visível sem precisar rolar muito, repetido no fim
- ✓Carrega rápido — poucas imagens pesadas, sem excesso de animação
✗ Landing que não funciona
- ✗Hero genérico tipo "Bem-vindo ao nosso site" sem dizer o que é
- ✗CTA escondido lá embaixo, ou nenhum CTA claro
- ✗Texto genérico de placeholder ("lorem ipsum" ou frases vagas tipo "somos os melhores")
💡 Dica Prática
Use essa lista de 4 seções como um checklist visual enquanto olha o resultado do agente: se conseguir apontar rapidamente onde está o hero, os benefícios, o CTA e o rodapé, a estrutura está certa — mesmo que o polimento visual ainda precise de ajuste no laço de screenshot (etapa 4, a seguir).
🎯 Etapas 1-3: objetivo, pasta de marca e prompt inicial
O build inteiro tem 7 etapas. As três primeiras são preparação — sem elas, o agente parte de contexto zero e o resultado volta a ser genérico, exatamente o problema do módulo 5.1.
Legenda: as 7 etapas em ordem — a 4 (laço de screenshot) é onde a maior parte do tempo é gasta, iterando; a 7 conecta direto com o módulo 5.8.
Defina o objetivo da landing
Escreva, antes de abrir o agente, uma frase única: o que ela vende/anuncia/apresenta e pra quem. Ex.: "landing pra captar interessados num curso de culinária pra iniciantes". Sem isso, o agente preenche a lacuna com genérico.
Reúna (ou crie) a pasta brand_assets
Se você já tem uma do módulo 5.6, é só apontar pra ela. Se não, use o prompt do 5.6 pra criar uma antes de seguir — pular esse passo é a causa mais comum de resultado sem identidade.
Escreva o prompt inicial, com a skill de design ativa
O prompt junta objetivo + pasta de marca + estrutura da seção anterior (hero/benefícios/CTA/rodapé) num só pedido. Veja o bloco copy-run abaixo.
Pedir a primeira versão da landing, com a skill de design (5.2) ativa e a pasta de marca (5.6) como fonte de verdade, já com a estrutura hero/benefícios/CTA/rodapé.
Use a skill de design pra construir uma landing page (index.html, self-contained) pra <descrição do objetivo: ex. "captar interessados num curso de culinária pra iniciantes">. Antes de escrever qualquer CSS, leia brand_assets/cores.md e brand_assets/tipografia.md e siga exatamente a paleta e a fonte de lá. Estrutura obrigatória: 1. Hero: título direto dizendo o que é + frase de apoio + botão CTA "<texto do seu CTA principal>" 2. Seção de benefícios: 3 a 4 cards com ícone + benefício concreto (não recurso técnico) 3. Seção de CTA reforçado, no meio ou perto do fim da página 4. Rodapé simples com <contato/redes/ano> Depois de gerar, tire um screenshot e me mostre — vamos rodar o laço de ajuste até bater com o padrão da marca.
✅ Como verificar
O primeiro screenshot já deve usar as cores exatas do cores.md (não uma aproximação) e ter as 4 seções presentes. Se alguma faltar, é sinal de que o agente pulou parte do prompt — peça pra revisar antes de seguir pra etapa 4.
🔁 Etapas 4-5: o laço de screenshot e a revisão manual
Novo aqui? O laço de screenshot (detalhado no módulo 5.3) é o agente rodar um ciclo: construir → tirar um print da tela → comparar com o que você pediu (ou com uma referência) → ajustar o que não bateu → tirar outro print → repetir. É o que transforma "eu chutei que ficou bom" em "eu vi que ficou bom".
Rode esse laço algumas vezes seguidas — normalmente 2 a 4 rodadas já resolvem a maior parte dos ajustes de espaçamento, alinhamento e contraste. Cada rodada, peça algo específico: "o botão do hero está pequeno demais, aumente", "o espaço entre os cards de benefício está apertado". Pedidos vagos tipo "melhore" geram ajustes aleatórios.
🔍 Por dentro
- Rodada típica: print → você aponta 1-3 problemas concretos → agente ajusta só esses pontos → novo print.
- Quando parar: quando o print bate com o que você tinha em mente e as 4 seções do tópico 2 estão presentes e claras.
Chegando na etapa 5, hora de ser honesto: mesmo depois do laço, existem coisas que ele não pega sozinho — exatamente o que o módulo 5.4 avisou. Timing de uma animação (rápida demais? lenta demais?), gosto pessoal de "o espaçamento aqui parece meio grande, mas não sei dizer por quê", e polimento fino de última milha. Essa revisão é sua, com os próprios olhos, abrindo a página de verdade — não só olhando um print estático.
💡 Dica Prática
Seja honesto com a expectativa: seguindo o processo inteiro, o resultado sai bem mais sólido que o genérico do módulo 5.1 — de um "~40%" pra algo perto de "~60%" de acabamento profissional. Mas não é 100%: ajuste fino de gosto pessoal, timing de animação e o último polimento continuam sendo trabalho seu. Isso não é falha do processo, é o que sobra pra você decidir.
🖥️ Etapas 6-7: testar em localhost antes de publicar
Novo aqui? Localhost ("host
local") é ver a página rodando no seu próprio computador, sem ela estar publicada na internet ainda — geralmente
um endereço tipo http://localhost:3000 que só
você (na sua máquina) consegue abrir. É o ensaio antes da estreia: você navega, clica nos links, testa em
tela de celular e computador, tudo sem ninguém de fora ver ainda.
Esse passo não é opcional. Um print está sempre um pouco "congelado" — não mostra se um link quebrou, se o menu não abre no celular, se o CTA não está clicável de verdade. Peça pro agente rodar a página localmente e abra você mesmo, testando pelo menos: os links funcionam, o layout não quebra numa tela estreita (celular), e o CTA principal realmente leva a algum lugar (mesmo que seja só um link temporário por enquanto).
✓ Teste em localhost completo
- ✓Abriu em tela de celular estreita, não só no monitor grande
- ✓Clicou em cada link/botão pra confirmar que reage
- ✓Recarregou a página do zero (não só olhou o resultado já carregado)
✗ "Testei" só de olhar o print
- ✗Só viu o screenshot do laço, nunca abriu a página de verdade
- ✗Não testou em tela estreita — layout pode quebrar no celular sem avisar
- ✗Foi direto pra publicação sem passar por localhost nenhuma vez
Pedir pro agente subir a landing localmente e te dar o endereço pra você abrir e testar com os próprios olhos.
Suba esta landing page em localhost pra eu testar antes de publicar. Me diga o endereço exato pra eu abrir no navegador. Depois que eu confirmar que testei, some as próximas etapas (deploy/ publicação) — vamos seguir isso no próximo módulo, com calma.
✅ Como verificar
Você conseguiu abrir o endereço local no navegador, ver a página completa (não erro de tela branca), e clicar em pelo menos 2 elementos interativos (link ou botão) confirmando que respondem.
Com o teste local aprovado, a etapa 7 é publicar ("deploy" — colocar a página no ar, num endereço acessível por qualquer pessoa na internet, não só na sua máquina). As regras detalhadas de como fazer isso direito — o que nunca automatizar sozinho, quando pedir confirmação, os cuidados com hospedagem — são o assunto inteiro do próximo módulo, o 5.8. Aqui, o marco que importa é: sua landing está pronta e testada, esperando só a etapa formal de publicação.
🧯 Erros comuns do build e checklist de publicação
Fechando o build, vale um raio-x dos deslizes mais comuns em quem faz esse processo pela primeira vez — e o checklist que evita cada um deles antes de você seguir pro módulo 5.8.
✓ Build bem conduzido
- ✓Objetivo escrito antes de abrir o agente, não decidido "no meio do prompt"
- ✓Pasta de marca existente e apontada explicitamente no prompt inicial
- ✓Pelo menos 2 rodadas do laço de screenshot antes de considerar pronto
- ✓Testado de verdade em localhost, em duas larguras de tela
✗ Build apressado
- ✗Pulou a pasta de marca, "vamos ver o que sai"
- ✗Aceitou o primeiro resultado do laço sem nenhuma rodada de ajuste
- ✗Publicou direto do print, sem abrir localhost nenhuma vez
- ✗Esperou 100% de acabamento antes de encerrar — build nunca fica "perfeito", fica bom o suficiente
📋 Checklist antes de considerar o build pronto
- ☐ Objetivo da landing está escrito e claro (o que ela vende/apresenta, pra quem)
- ☐ Pasta
brand_assets/existe e foi consultada no prompt - ☐ As 4 seções básicas estão presentes: hero, benefícios, CTA, rodapé
- ☐ Pelo menos 2 rodadas do laço de screenshot rodaram
- ☐ Você mesmo abriu em localhost e testou links + tela estreita
- ☐ Está honesto consigo: sabe que ficou ~60%, não 100% — e isso está OK
Checagem rápida (opcional): por que testar em localhost antes de publicar, se o laço de screenshot já mostrou a página funcionando?
📝 Exercício
Publique sua própria landing page: escolha um objetivo real (pode ser fictício, tipo um produto imaginário — o que importa é praticar o processo inteiro), rode as 7 etapas deste módulo do início ao fim, e chegue até o teste aprovado em localhost. Guarde o link do repositório/pasta do projeto — você vai usá-lo direto no módulo 5.8 pra completar a publicação.