Construindo o site da We Love Chile do zero ao ar, print por print.

Este caderno acompanha a aula passo a passo. A regra da aula é uma só: você não assiste, você constrói junto. Enquanto o site da We Love Chile nasce na tela, o do seu negócio nasce no seu computador.

O curso é cumulativo: tudo que você aprendeu no Claude Basics continua valendo, e o que a gente fizer aqui volta nas próximas aulas.

Antes de escrever qualquer linha, a gente descobre o que já está funcionando no mercado. Quem chuta layout começa do zero. Quem olha o mercado já começa lá na frente.

1. Inteligência competitiva: pesquisar e raspar os melhores sites do seu mercado.
2. Brief de design: transformar essa pesquisa num documento que vira instrução de construção.
3. Construção e deploy: três versões em paralelo, escolher a melhor, publicar.

Cada etapa é, no fundo, um prompt bem feito.

Abra o Claude na sua WeWiki, porque é lá que mora o seu time inteiro, cada um com o contrato e os SOPs que vocês construíram juntos. Se você abrir direto numa pasta de projeto, os agentes até respondem pelo nome, mas sem o manual deles: o Félix vira "um dev qualquer" em vez do SEU Félix.

Agora a parte onde a maioria erra: a pasta do site NÃO vai dentro da WeWiki, e você também não precisa criar ela na mão.

Larry, eu vou construir o site da We Love Chile. Cria a pasta do projeto fora da WeWiki, num lugar que faça sentido, e me diz o caminho completo.

A WeWiki é markdown puro, a sua biblioteca de conhecimento. Código não mora lá. Sua wiki guarda o que você sabe; seu site é um produto. Cada um na sua casa.

Se você ainda não tem WeWiki, o caminho é mais curto: cria uma pasta pro projeto e abre o Claude direto nela. O resto da aula é igual.

• Sempre o caminho completo. Nos prompts, nunca escreva só versao-1/: dê o endereço inteiro da pasta, senão ele grava no lugar errado e você vai catar arquivo perdido depois.
• Renomeie toda conversa. No Claude app cada aba é um contexto próprio; no terminal cada aba é um Claude. Daqui a pouco você tem quatro abertas e não sabe qual é qual. Essa primeira aqui chama "pesquisa".
• No terminal, sem pedir licença a cada passo. Em vez de claude, digite claude --dangerously-skip-permissions. O nome entrega o que é: use só dentro da pasta do projeto e só depois de pegar o jeito.

Você não vai construir sozinho: o time de WeAgents entra em campo inteiro, com você no papel de diretora despachando o trabalho.

O dono deste passo no seu time é o Pax, seu pesquisador. É ele quem mergulha nos concorrentes e volta com o dossiê e a matriz. Se o Firecrawl (ou qualquer API desta aula) ainda não estiver conectado, despache o Mack: conexão de API e MCP é o trabalho dele.

Oi Pax, eu quero criar o site da We Love Chile, uma empresa brasileira de passeios no Chile pra brasileiros: englobando passeios em Santiago, Deserto do Atacama e Patagônia. Use o Firecrawl e encontre os melhores sites de agências de passeios e turismo receptivo que estão dando resultado, no Brasil e no mundo (procure as mais bem ranqueadas no Google, GetYourGuide, Civitatis, etc). Identifique uma lista grande, escolhe os top 5 sites, crie uma matriz de avaliação (reviews, ranking de SEO, clareza da oferta, o que fizer sentido). Me entregue o relatório em um HTML premium dos 5 melhores e depois uma análise do que esses 5 fazem em comum que os piores não fazem, pra gente usar esses princípios no nosso site. Me pergunta o que precisar.

Você só troca o tipo de negócio: consultoria, doce artesanal, curso, serviço B2B. O template genérico, com colchetes pra preencher, está nos entregáveis no fim deste caderno.

Repare: ele não sai correndo pesquisar. Volta perguntando quem exatamente é o seu cliente (porque "empresas" é largo demais e os melhores concorrentes mudam conforme o avatar) e qual é o seu ângulo. Responda com o mínimo necessário.

Meu cliente é o brasileiro indo pro Chile pela primeira vez, que quer neve e aventura mas tem insegurança logística: idioma, altitude, o que reservar, como reservar. Meu ângulo é segurança e acolhimento. O site inteiro precisa ser em português. Não se preocupa com posicionamento agora, quero que a pesquisa me mostre isso.

Se o relatório vier em texto corrido e você quiser ele bonito, é só pedir: "cria um HTML pra mim com isso".

O que volta é ouro: grade de pontuação, comparativo dos sites e padrões claros. No caso do turismo, por exemplo: os melhores mostram preço na primeira dobra, usam prova social perto do botão de reserva e têm página dedicada por passeio, não um catálogo genérico.

Copie todas as informações do relatório, clique em "novo arquivo" na barra lateral, nomeie principios.md e cole tudo lá dentro.

Aqui eu não digito nada na mão. Duas coisas já existem prontas: o design system da marca, que a Iris construiu (paleta, tipografia, espaçamento, direção de imagem), e a Central de Inteligência da marca, onde moram os oito contextos do negócio (identidade, história, público, produto, voz, visual, diferenciais e mercado).

Lê o design system da We Love Chile e a Central de Inteligência da marca, e monta pra mim o marca.md com o que interessa pra construir o site.

Ele volta com o arquivo pronto: paleta com códigos de cor e proporção de uso, fonte de título e de corpo, tom de voz e público. Nenhuma dessas linhas foi escrita na mão: elas já existiam, só estavam em outro lugar. Você aponta, ele busca.

O arquivo de marca é a constituição visual: todo artefato que o time gerar (site, imagem, deck) nasce referenciando o design system e o logo, e é por isso que tudo sai com a mesma cara sem ninguém pedir.

Oi, se familiariza com o principios.md e com o marca.md. A gente vai construir juntos o site da We Love Chile, empresa de passeios no Chile pra brasileiros. Me avisa quando entender o brief e a gente começa.

Ele volta perguntando um monte de coisa, e é aqui que a galera trava querendo explicar demais. O nome do negócio você dá (se ainda não tem, inventa um provisório e troca depois numa frase). A oferta deixa geral, sem cravar nicho: o recorte fino você faz no story, no anúncio, na abordagem, e o site tem que caber em todos. E fecha com: "usa os melhores recursos e bibliotecas que existirem pra deixar isso o mais lindo e interativo possível".

Se você ainda não tem identidade visual nenhuma, relaxa: pede pro Claude propor uma paleta e uma tipografia a partir do principios.md, escolhe a proposta que mais parece com você, e salva no seu marca.md. Pronto, agora você tem.

O principios.md guarda o que o mercado provou. O marca.md guarda a sua identidade. Falta o terceiro arquivo da tríade, e esse é o mais importante: o CLAUDE.md.

Ele é a constituição do projeto, e a graça é essa: o Claude lê esse arquivo sozinho, toda vez que você abre uma sessão naquela pasta. Você escreve a regra uma vez e nunca mais repete em prompt nenhum.

Só que tem um jeito melhor de criar esse arquivo do que sentar e escrever regra no chute: um protocolo chamado PLANO. Você cola um prompt no primeiro minuto do projeto, ele te faz cinco perguntas e escreve o CLAUDE.md pronto. O prompt inteiro está nos entregáveis, no fim deste caderno.

• Estrela-guia: qual é o único resultado que significa que a gente ganhou?
• Integrações: de quais serviços de fora isso depende, e as credenciais já estão na mão?
• Fonte de verdade: onde mora o dado principal?
• Entrega: como e onde o resultado final tem que aterrissar?
• Regras de comportamento: como o sistema deve agir, o que ele sempre faz, o que ele nunca faz.

No site da We Love Chile eu respondi: a estrela-guia é a pessoa clicar em "quero conhecer o Chile" e cair no meu WhatsApp; as integrações são Firecrawl, GitHub e Cloudflare; a fonte de verdade são o principios.md e o marca.md; a entrega é o site no ar no domínio da marca. E as regras de comportamento foram estas três:

Sempre use a skill de design antes de escrever código de frontend.
Teste tudo em localhost numa porta alta livre e só faça push quando eu mandar.
Nunca troque a paleta sem me perguntar.

• P de Propósito: a planta. As cinco perguntas e o formato do dado, antes de existir uma linha de código.
• L de Ligações: conferir que cada conexão de fora responde de verdade, e parar tudo se alguma estiver quebrada.
• A de Arquitetura: separar a lógica em três camadas (procedimentos em markdown, a navegação que decide o que chamar, e os scripts que fazem o trabalho). Regra de ouro: mudou a lógica, atualiza o procedimento ANTES do código.
• N de Nível: acabamento e verificação. Nada é entregue sem um teste ou um print provando que funciona.
• O de Operação: o deploy e o que acontece quando quebra.

• A pasta de memória. O Claude cria quatro arquivos e alimenta eles sozinho enquanto trabalha: o plano, os achados, o progresso e as decisões (com o motivo de cada uma). Você fecha o computador na terça, volta na sexta, e ele sabe exatamente onde parou e por quê.
• O loop de conserto. Quando algo quebra ele não chuta: lê o erro de verdade, conserta, testa, e escreve a lição no procedimento. É isso que faz o mesmo erro não voltar na semana seguinte.

E tem uma regra que parece chata e é justamente a que salva: enquanto as cinco perguntas não estiverem respondidas e o formato do dado não estiver definido, ele está proibido de escrever código. Trava mesmo. Parece que atrasa, mas é o contrário: código escrito antes da decisão é código que você joga fora.

Depois que o arquivo nasce, ele vira vivo: toda instrução que você se pegar repetindo pela terceira vez, fala "isso vira regra" e manda adicionar ali.

Você não vai construir um site. Vai construir três ao mesmo tempo e escolher o melhor.

Por quê? O mesmo prompt, rodado dez vezes, produz dez sites completamente diferentes: layout, hierarquia e vibe diferentes. Se você roda só um, fica refém do primeiro palpite.

E o pulo do gato: não são três tentativas iguais torcendo pela sorte, são três estratégias diferentes, três sabores distintos pra você provar. Quem põe a mão na massa é o Félix: pense em cada conversa aberta como um Félix construindo uma versão, e você como a diretora comparando os resultados.

• Versão 1, do melhor concorrente. Volta no relatório do Passo 1, acha o site com a nota mais alta em design. Um layout que já provou que funciona no seu mercado.
• Versão 2, da sua marca. Só o design system, sem olhar concorrente nenhum. É o site que a sua identidade pediria se ninguém mais existisse.
• Versão 3, do awesome-design-systems. O repositório com o manual de estética das maiores marcas do mundo (Stripe, Linear, Vercel, Airbnb). O rigor de um time de design de primeira linha aplicado no seu conteúdo.

Uma versão puxa pro que o mercado validou, outra puxa pra sua identidade, a terceira puxa pra excelência de design. Três forças diferentes, e é por isso que os resultados saem tão distintos.

Renomeie as abas: "versão concorrente", "versão marca" e "versão awesome design". Nunca "conversa 2": você quer bater o olho e já saber de onde veio aquela versão. E avise cada um deles que os outros existem, senão um mexe no arquivo do outro e vira bagunça.

Os três prompts completos, genéricos e no caso real da We Love Chile, estão nos entregáveis no fim deste caderno.

As três conversas rodam ao mesmo tempo. Você toma um café e volta com três sites prontos. Aí é só pedir: "abre as três versões pra mim em localhost, pra eu ver tudo junto".

Vá treinando o olho pra uma coisa: quase sempre uma das três tem cara de IA, aquele visual genérico que você já viu em mil sites. Não é a mais feia, é a mais previsível. Descarta sem dó. E se bater o olho e quiser mudar algo, fala na hora: ele troca e você segue comparando.

No caso da We Love Chile, a versão 3 ganhou, a que veio do awesome-design-systems: o rigor de espaçamento, a escala tipográfica e o grid vieram de um time de design de primeira linha, e com as cores e as fontes da marca por cima o site ficou perfeito. E olha que interessante: a que veio do melhor concorrente ficou bem-feita, mas ficou com cara de concorrente, não parecia minha.

Um passo que quase ninguém faz e que custa dez minutos. Você tem uma vencedora; antes de seguir, roda ela de novo com outro cérebro. O ponto não é trocar de ferramenta: é que modelo diferente resolve o mesmo brief de um jeito diferente, e às vezes o outro te dá uma solução de layout que o primeiro nem cogitou.

Uma das três coisas acontece: a do Claude continua melhor e você segue tranquila, a do Codex ficou melhor e você adota, ou (o mais comum) cada uma acertou numa parte. Nesse caso fica com a melhor como base e pede pro Claude recriar só o pedaço bom da outra.

O site está lindo, mas está preso no seu computador. Pra mandar pra alguém, você precisa de uma URL de verdade. A dupla que resolve isso: GitHub, onde o código vive (um Google Drive de código, com versões infinitas), e Cloudflare Pages, onde o site fica hospedado.

Aqui eu vou contra o que a maioria ensina, que é publicar na Vercel. Eu recomendo o Cloudflare e é o que eu uso em tudo meu: o plano grátis não tem limite de visita, a rede é a mais rápida do mundo, e domínio, DNS, certificado e hospedagem ficam no mesmo lugar. Se você preferir a Vercel, tudo aqui funciona igual, é só trocar o nome nos prompts.

1. "Conecta no GitHub via CLI. Se já estiver conectado, só confirma."
2. "Cria um repositório no GitHub com esse projeto inteiro."
3. "Conecta no Cloudflare via CLI, usando o Wrangler. Se já estiver conectado, só confirma." (abre uma janelinha de autorização, você clica em permitir uma vez)
4. "Publica isso no Cloudflare Pages."

E emenda o quinto, o do pós-deploy: "ativa o Web Analytics do Cloudflare nesse site". A partir daí você vê quantas pessoas entram, de onde vêm e a velocidade real em cada aparelho, sem configurar nada na mão. E o Cloudflare mede isso sem cookie de rastreamento, então você não precisa daquele popup chato de consentimento.

GitHub tem fama de lugar de nerd, mas não é: é a sua pasta de projeto com o histórico inteiro do que mudou. Em configurações, lá no fim, está escrito que o repositório é privado: só você enxerga esse código. É assim que ele nasce e é assim que deve ficar enquanto for o site do seu negócio.

Com o site no GitHub, cada mudança vira um estado salvo, como save de jogo. O Claude fez uma mudança que quebrou alguma coisa? "Volta pra versão anterior." Ele reverte, pronto.

E isso muda o seu comportamento: você perde o medo de mexer, passa a pedir mudança, experimentar, iterar. É aí que o site fica bom de verdade.

O Cloudflare te dá uma URL temporária meio esquisita, tipo site-a3f.pages.dev. Funciona, mas não passa confiança. Essa parte é do Dom, o agente de domínios: pesquisa de nome, registro e apontamento é com ele, você só aprova o endereço.

1. No painel do Cloudflare, entra no seu projeto do Pages e vai em "domínios personalizados".
2. Se o domínio já é seu, é só apontar.
3. Se ainda não tem, compra ali mesmo, na área de registro de domínios do Cloudflare.

Comprar o domínio no mesmo lugar onde o site está hospedado economiza a parte mais chata: DNS e certificado de segurança se configuram sozinhos. A propagação leva uns minutos, porque os servidores do mundo precisam aprender que esse endereço existe.

Dois acabamentos antes de sair divulgando: peça o redirect 301 permanente das variantes do domínio (com www e sem www) pro endereço principal, e confira se o cadeado HTTPS aparece no navegador. Se aparecer "não seguro", fala pro Claude que ele resolve o processo inteiro.

O site está no ar. Agora a gente faz ele ser encontrado. Skills são pacotes de capacidade especializada que você entrega pro Claude, tipo contratar um especialista pra uma tarefa pontual.

A que a gente usa aqui é de graça, mora no GitHub e é a mesma que os profissionais usam: github.com/AgriciDaniel/claude-seo. Você entra no repositório, copia o link e cola no Claude falando "usa esse repositório pra melhorar o SEO do meu site". Ele baixa e instala sozinho.

Ela identifica as palavras-chave certas do nicho, otimiza o copy das páginas, aplica schema markup (um código invisível que ajuda o Google a entender o site) e estrutura os títulos pra ranquear.

Quero ranquear pra "passeios em Santiago", "Valle Nevado bate e volta", "vinícolas perto de Santiago" e "Valparaíso em um dia". Cada passeio precisa da sua própria página otimizada, porque a pesquisa mostrou que os melhores sites do nicho fazem exatamente isso. Acha o equilíbrio entre ranquear e converter, e aplica tudo dessa skill.

Quando terminar, me dá uma lista detalhada, com um item por linha e uma marcação de concluído em cada um, explicando cada melhoria que você fez. Depois disso publica no GitHub e no Cloudflare.

Ele não sai otimizando às cegas: primeiro devolve um diagnóstico, e é lindo de ver. Fala o que você está vendendo de verdade, descreve quem é o seu comprador, lista os termos de busca que fazem sentido e separa por prioridade. Aí sim aplica.

Percebe o pulo do gato? As keywords do SEO saíram da pesquisa competitiva do começo da aula. Nada aqui é achismo: o pipeline se alimenta.

A verdade que ninguém conta nos tutoriais: site bonito que não vende é um cartão de visita caro. E o motivo é um só: ninguém lê site, as pessoas olham de relance. Se em 3 segundos o visitante não entendeu o que você vende e o que fazer, ele foi embora.

• H1 com no máximo 7 palavras: quem chega precisa entender a oferta num relance, sem esforço.
• Um único CTA, repetido: "quero conhecer o Chile" aparece várias vezes, e é sempre o MESMO botão, não cinco convites disputando o clique.
• Prova social perto do botão: logos, números e avaliações coladas no CTA, nunca escondidas no rodapé.
• Cortar densidade de texto sem dó: cada parágrafo que você corta aumenta a chance dos que ficaram serem lidos.
• Preço visível cedo: quando o negócio permite mostrar, esconder preço só gera desconfiança (e a pesquisa confirmou: os melhores do nicho mostram).

Revisa o site inteiro com foco em conversão: H1 de até 7 palavras, um único CTA repetido, prova social colada nos botões, metade do texto atual, e preço visível antes da terceira dobra.

Você acabou de construir o site. Você está apaixonada por ele. E por isso mesmo você não enxerga mais os defeitos. Isso é humano.

A solução: abre uma janela nova do Claude, contexto limpo, zero histórico da construção.

Oi, quero que você aja como um crítico duro. Entra nesse site, encontra inconsistências, copy que não faz sentido, design estranho, e volta com uma lista priorizada: crítico, alto, médio, baixo. Não precisa inventar problema onde não existe, mas olha de verdade, pra esse site ficar o mais efetivo e honesto possível. E traz qualquer repositório do GitHub que você achar relevante pra resolver o que encontrar.

Aquela última frase parece boba e é a que faz diferença: sem ela ele só opina com o que tem na cabeça. Com ela, ele busca a referência de fora e volta com o conserto na mão, não só com o diagnóstico.

No meu caso ela pegou duas coisas: um card de passeio sem preço (os melhores sites do nicho sempre mostram) e um botão que dizia "saiba mais" onde devia dizer "reservar meu lugar".

• Inteligência competitiva via Firecrawl, antes de construir qualquer coisa.
• Brief em dois arquivos: principios.md com o que o mercado provou e marca.md com a identidade.
• Janela nova pra construir: contexto limpo constrói site limpo.
• Três agentes em paralelo no Fable 5, e uma vencedora.
• Passo extra com o Codex: a vencedora refeita por outro cérebro.
• Deploy GitHub mais Cloudflare Pages via CLI: URL real no ar com quatro prompts.
• Controle de versão: liberdade de mexer sem medo de quebrar.
• Skill de SEO, com as keywords vindas da pesquisa.
• Conversão e copy: H1 de até 7 palavras, um CTA só e prova social perto do botão.
• Auditoria crítica em janela nova: o segundo olhar que pega o que a paixão esconde.

O que ficou de fora de propósito: formulário que grava de verdade, contas de usuário e área admin precisam de backend, e isso é assunto da aula de Aplicativos.

• Extrator de código-fonte de site: view-page-source.com (cola a URL do concorrente e baixa o HTML)
• Repositório open-design: github.com/nexu-io/open-design (a alternativa aberta ao Claude Design)
• Skill de SEO: github.com/AgriciDaniel/claude-seo
• Hospedagem: Cloudflare Pages (plano grátis sem limite de visita, domínio e certificado no mesmo lugar)

Os links de componente pronto (21st.dev e CodePen) e a skill de UI e UX ficam na Aula 02, junto com a passada de design.

Cole este prompt antes de qualquer outra coisa, no primeiro minuto do projeto. Ele te faz cinco perguntas e escreve sozinho a constituição do projeto. Serve pra qualquer projeto: site, aplicativo, agente, automação.

Você é o Piloto de Sistema. Sua missão: construir sistemas determinísticos e
auto-reparáveis no Claude Code, usando o protocolo PLANO (Propósito, Ligações,
Arquitetura, Nível, Operação) e a construção em 3 camadas (Arquitetura, Navegação
e Ferramentas). Confiabilidade acima de velocidade. Nunca chute regra de negócio.

=== PROTOCOLO 0 · INICIALIZAÇÃO (OBRIGATÓRIO) ===

Antes de escrever qualquer código ou construir qualquer ferramenta:

1. Crie a memória do projeto em /memoria/:
   - plano.md      -> fases, objetivos, checklists
   - achados.md    -> pesquisa, descobertas, restrições
   - progresso.md  -> o que foi feito, erros encontrados, testes rodados, resultados
   - decisoes.md   -> escolhas de arquitetura e o motivo de cada uma

2. Crie o CLAUDE.md na raiz do projeto, como Constituição do Projeto:
   - Formato dos dados (formato de entrada -> formato de saída)
   - Regras de comportamento
   - Invariantes de arquitetura
   - As saídas das 5 fases do PLANO, preenchidas conforme avançarmos

3. PARE A EXECUÇÃO. Você está proibido de escrever lógica em /execucao/ enquanto:
   as perguntas do Propósito não estiverem todas respondidas, o formato dos dados
   não estiver definido no CLAUDE.md, e o plano.md não tiver um Propósito aprovado.

=== FASE P · PROPÓSITO (visão e lógica) ===

1. Descoberta: me faça estas cinco perguntas, UMA DE CADA VEZ, esperando cada
   resposta antes da próxima:
   - Estrela-guia: qual é o único resultado que significa que a gente ganhou?
   - Integrações: de quais serviços externos isso depende (Slack, Notion, Gmail,
     Stripe, Planilhas, etc.)? As credenciais já estão prontas?
   - Fonte de verdade: onde mora o dado principal?
   - Entrega: como e onde o resultado final deve aterrissar?
   - Regras de comportamento: como o sistema deve agir? (tom, o que sempre fazer,
     o que nunca fazer, quando recusar)

2. Regra dos dados primeiro: defina o formato JSON dos dados (entrada e saída) no
   CLAUDE.md. O código só começa depois que eu confirmar o formato da entrega.

3. Pesquisa: procure repositórios, documentação e trabalho anterior que acelerem
   esta construção. Registre o que achar em /memoria/achados.md.

=== FASE L · LIGAÇÕES (conectividade) ===

1. Verificação: teste cada conexão de API e cada credencial listada na fase P.
   Documente o resultado de cada uma em /memoria/progresso.md.

2. Aperto de mão: construa scripts mínimos de teste em /execucao/ que confirmem
   que cada serviço externo responde. Conexão quebrada = pare tudo. Não avance
   para a lógica enquanto todas as conexões não estiverem verdes.

=== FASE A · ARQUITETURA (a construção em 3 camadas) ===

Modelos de linguagem são probabilísticos; regra de negócio precisa ser
determinística. Então separe:

A · Arquitetura (/arquitetura/)
   - Procedimentos técnicos escritos em markdown
   - Objetivos, entradas, lógica das ferramentas, casos de exceção
   - Regra de ouro: se a lógica mudar, atualize o procedimento ANTES do código

N · Navegação (camada de decisão)
   - Raciocínio e roteamento
   - Leva o dado entre os procedimentos e as ferramentas
   - Não executa tarefa complexa por conta própria: chama as ferramentas na ordem certa

F · Ferramentas (/execucao/)
   - Scripts determinísticos, atômicos e testáveis
   - Credenciais vivem no .env (ou equivalente da plataforma)
   - Todo arquivo intermediário passa por /.tmp/

=== FASE N · NÍVEL (refino e entrega) ===

1. Refino da entrega: formate cada saída (blocos do Slack, layout do Notion, HTML
   de e-mail, cards de dashboard, exportação de documento) com qualidade de entrega.

2. Interface: se o projeto tiver frente visual, aplique estilo limpo e layout
   intuitivo.

3. Verificação: toda saída vai acompanhada de um teste, um print ou um comando de
   uma linha que comprove. Se você não consegue comprovar, não entrega.

4. Aprovação: me mostre o resultado acabado e espere meu aval antes de publicar.

=== FASE O · OPERAÇÃO (publicação e auto-reparo) ===

1. Transferência: leve a lógica finalizada do teste local para produção.

2. Automação: configure o disparo (agendamento, webhook, comando manual, escuta de
   evento). Documente cada gatilho no CLAUDE.md.

3. Registro de manutenção: finalize a seção de estabilidade de longo prazo do
   CLAUDE.md.

4. Loop de auto-reparo: quando algo quebrar:
   a. Analise: leia o erro e o rastro da falha. Não chute.
   b. Conserte: corrija o script em /execucao/.
   c. Teste: comprove que o conserto funciona.
   d. Atualize a arquitetura: escreva a lição no procedimento correspondente em
      /arquitetura/, pra o mesmo erro nunca mais se repetir.

=== PRINCÍPIOS DE OPERAÇÃO ===

1. Dados primeiro: formato de entrada e saída definidos antes de rodar código
2. Mudança cirúrgica: mexa só no que foi pedido
3. Simplicidade primeiro: lógica mínima, nada de abstração especulativa
4. Guiado pelo objetivo: toda mudança medida contra a estrela-guia e o passo de
   verificação
5. Ritmo por tarefa: explorar -> planejar -> codar -> commitar. Sem pular etapa.

=== ENTREGA FINAL vs INTERMEDIÁRIO ===

- /.tmp/                     -> descartável. Logs, dados raspados, rascunhos.
- Destino final              -> a entrega de verdade. Planilha, banco, mensagem,
                                dashboard, documento. O projeto só está "pronto"
                                quando a entrega aterrissa no destino.

=== ESTRUTURA DE ARQUIVOS (PADRÃO) ===

├── CLAUDE.md            # Constituição do Projeto + acompanhamento de estado
├── .env                 # Credenciais (verificadas na fase L)
├── /memoria/            # Memória viva do projeto
│   ├── plano.md
│   ├── achados.md
│   ├── progresso.md
│   └── decisoes.md
├── /arquitetura/        # Camada A: procedimentos (o "como fazer")
├── /execucao/           # Camada T: scripts (os "motores")
└── /.tmp/               # Bancada temporária

Template genérico, pronto pra qualquer pessoa colar e só trocar o que está entre colchetes.

Oi Claude, eu quero construir o site do meu negócio.

Meu negócio: [DESCREVA EM UMA FRASE O QUE VOCÊ VENDE E PARA QUEM]
Onde eu opero: [CIDADE, ESTADO OU PAÍS]
Quem eu quero que você pesquise: [TIPO DE EMPRESA CONCORRENTE, POR EXEMPLO
"clínicas de estética", "escritórios de contabilidade", "agências de viagem"]

O que eu preciso de você, nesta ordem:
1. Use o Firecrawl para levantar uma lista grande de sites desses concorrentes, os que
   mais dão resultado. Pode incluir referências de fora da minha região se forem
   relevantes.
2. Crie uma matriz de avaliação para julgar esses sites. Você escolhe os critérios e os
   pesos, pode ser reviews do Google, ranking de SEO, clareza da oferta, facilidade de
   comprar, prova social, qualidade do texto, o que fizer mais sentido para o meu
   mercado. Me mostre a matriz antes de aplicar.
3. Aplique a matriz, pontue todos os sites e me entregue o ranking completo.
4. Me entregue um relatório detalhado dos 5 melhores: o que cada um faz bem, o que faz
   mal, e a nota critério por critério.
5. Faça a análise oposta, dos 5 piores, e me diga o que os melhores têm em comum que os
   piores não têm.
6. Transforme isso em princípios práticos para o meu site, com um checklist do que é
   obrigatório e do que é desejável.

Me faça todas as perguntas que precisar antes de começar.

Meu cliente é [QUEM COMPRA DE VOCÊ, EM UMA FRASE]. Meu diferencial é [O QUE VOCÊ FAZ
DIFERENTE]. Não se preocupe com posicionamento agora, eu quero que isso apareça na
pesquisa, não quero pré-enviesar.

Uma conversa pra cada, todas com o modelo Fable 5 (digite /model e selecione antes de mandar o prompt). Cada versão grava na pasta dela, e você compara as três no final.

Se familiarize com o principios.md e o marca.md.

No relatório de concorrentes, o site com a melhor nota de design foi:
[COLE A URL DO SITE MELHOR AVALIADO NA MATRIZ]

Vá até esse site e entenda a estrutura e a linguagem visual dele: hierarquia do
hero, ordem das seções, ritmo de espaçamento, onde ele coloca prova social e onde
coloca os CTAs.

Construa o nosso site com essa mesma estrutura, mas com o NOSSO conteúdo e com as
cores e fontes do marca.md, que essas mandam sempre. Isso é inspiração de layout,
não é cópia: não quero uma linha de código dele no nosso site.

Existem outros dois agentes construindo versões diferentes em outras pastas. Você
trabalha só dentro da sua. Grave tudo em [CAMINHO COMPLETO DA PASTA DO SITE]/versao-1/.

Se familiarize com o marca.md e com o design system da minha marca.

Ignore concorrente. Não olhe nenhuma referência de fora.

Construa o site que essa marca pediria se ninguém mais existisse: as cores, a
tipografia, a escala de espaçamento, o tom de voz e a direção de imagem que estão
no design system, levados a sério do começo ao fim.

Use o principios.md apenas para saber quais seções precisam existir, nunca para
copiar visual de ninguém.

Existem outros dois agentes construindo versões diferentes em outras pastas. Você
trabalha só dentro da sua. Grave tudo em [CAMINHO COMPLETO DA PASTA DO SITE]/versao-2/.

Se familiarize com o principios.md e o marca.md.

Construa usando a linguagem de design deste repositório:
[COLE O LINK DA MARCA ESCOLHIDA NO awesome-design-systems]

Aplique o rigor deles em espaçamento, escala tipográfica, grid e comportamento dos
componentes. Mas as cores e as fontes são as do marca.md, essas mandam sempre.

Existem outros dois agentes construindo versões diferentes em outras pastas. Você
trabalha só dentro da sua. Grave tudo em [CAMINHO COMPLETO DA PASTA DO SITE]/versao-3/.

Servem de exemplo de como fica quando os colchetes estão preenchidos.

[VERSÃO 1 · MELHOR CONCORRENTE]
Se familiarize com o principios.md e o marca.md. Abra o relatório de concorrentes e
identifique o site melhor rankeado pela matriz no quesito design. Vá até ele e
entenda a estrutura: quais seções existem, como o preço aparece na tela, onde a
prova social se posiciona e como o visitante chega até a reserva.
Construa o site da We Love Chile com essa mesma estrutura, mas com o nosso conteúdo
(destinos Santiago, Atacama e Patagônia, sendo a Patagônia marcada como em breve;
Valle Nevado, vinícolas e Valparaíso entram como passeios dentro de Santiago),
em português do Brasil, e com as cores e fontes do marca.md, que essas mandam
sempre. É inspiração de layout, não é cópia: não quero uma linha de código deles no
nosso site. Existem outros dois agentes construindo em outras pastas. Grave em
versao-1/.

[VERSÃO 2 · DESIGN SYSTEM DA MARCA]
Se familiarize com o marca.md e com o design system da We Love Chile. Ignore
concorrente e não olhe referência de fora. Construa o site que a We Love Chile
pediria se ninguém mais existisse: creme #F3E8D5 de fundo na proporção 60-30-10 com
o azul #1E55B5 e o vermelho #DB3A3D, Lufga no corpo e Chalkiez só nas frases curtas
de impacto, tom de amiga que já foi ao Chile dezenas de vezes, foto grande de neve e
cordilheira mandando na composição. Use o principios.md só para saber quais seções
precisam existir. Existem outros dois agentes construindo em outras pastas. Grave em
versao-2/.

[VERSÃO 3 · AWESOME DESIGN SYSTEMS]
Se familiarize com o principios.md e o marca.md. Construa usando a linguagem de
design do design system do Airbnb no repositório awesome-design-systems, que é a
marca do repositório com mais afinidade com viagem. Aplique o rigor deles em espaçamento, escala tipográfica, grid e comportamento dos
componentes. Mas as cores e as fontes são as da We Love Chile no marca.md, essas
mandam sempre. Existem outros dois agentes construindo em outras pastas. Grave em
versao-3/.

Rode este na mesma pasta do projeto, depois de escolher a vencedora. Troque o nome da pasta pela sua vencedora.

Nesta pasta estão o principios.md, o marca.md e o site já pronto em [PASTA DA
VERSÃO VENCEDORA, POR EXEMPLO versao-3/]. Leia os três.

Construa a sua própria versão desse mesmo site em versao-codex/, com o mesmo
conteúdo, a mesma marca e as mesmas seções, mas resolvendo o design do seu jeito.

Não copie o que já está na pasta da versão vencedora: eu quero ver a sua leitura do
mesmo brief, não uma repetição.

Quando terminar, abra em localhost numa porta alta livre e me diga em três linhas o
que você fez diferente e por quê.