Build Multilanding
Uma página genérica é uma promessa para ninguém. O tráfego pago chega com uma pergunta específica, e a página ou continua a conversa que o anúncio iniciou ou recomeça do zero às custas do visitante. Esta skill constrói o primeiro tipo: um sistema de landing pages sustentável onde cada URL mantém uma promessa para uma intenção, e cada variante é uma hipótese testável com sua própria trilha de papel do clique do anúncio à receita.
Construa um sistema, não páginas copiadas. Cada linha da tabela de variantes é uma hipótese de marketing; cada URL é uma visão do mesmo sistema de componentes. O retorno para o tráfego pago: promessas mantidas aumentam a relevância e a confiança, o que eleva a conversão e reduz o custo de cada lead qualificado. Esse é o caso de negócios completo, e é por isso que o trabalho começa com contratos, não com texto.
A skill é o MOTOR (método, contratos, portões, scripts). O projeto é o COMBUSTÍVEL (seus próprios públicos, ofertas, palavras-chave, provas). O motor nunca armazena ou inventa os públicos ou palavras-chave de um projeto. Leia references/input-contract.md primeiro. Para ver todo o método em miniatura, leia references/worked-example.md: uma oferta, três intenções, três páginas diferentes.
Segmente por intenção, não por dado demográfico
A unidade é intenção de busca distinta + estágio de consciência + oferta + mensagem = uma experiência de landing page. Vários públicos podem compartilhar uma página; um
público pode precisar de várias páginas. Agrupe palavras-chave por significado,
não por pequenas variações de string.
Veja references/intent-and-message-match.md.
Comece com o contexto do projeto
- Leia
.agents/product-marketing.md(fonte estratégica da verdade) através domarketing/source-map.yamldo projeto. Fallback:.claude/product-marketing-context.md. - Leia o briefing da campanha para o lançamento. Carregue apenas as intenções, mensagens, ofertas e provas vinculadas.
- Classifique cada fato como confirmado / derivado / hipótese / desconhecido.
- Se uma oferta confirmada, ação de conversão, hipótese de público/intenção ou a
prova necessária estiver faltando, produza um relatório de lacuna de contexto e pare. Execute
scripts/validate_inputs.py.
Trabalhe em portões (gates)
Portão 1: estratégia e contratos
Construa a matriz de intenções. Para cada variante, escreva um contrato de landing antes de qualquer texto: o que o buscador quer, o que o anúncio promete, o que a página promete, uma CTA, prova necessária, objeções, ação de conversão e valor, evidência.
Portão 2: conceitos representativos
Construa e revise 3-5 conceitos deliberadamente diferentes, incluindo o texto mais longo realista e um caso de estresse móvel. Não gere em escala antes que isso passe pela revisão.
Portão 3: compor e dimensionar
Componha páginas com o compositor modular, não com um modelo PAS fixo
(references/page-composer.md); escolha a estrutura
pelo estágio de consciência. Gere variantes a partir de campos validados
(references/variant-schema.md). Rejeite
ids/slugs duplicados, campos obrigatórios vazios, enums inválidos, alegações
não verificáveis e mapeamentos campanha/criativo incompatíveis via
scripts/validate_variants.py.
Portão 4: conversão, rastreamento, privacidade
Torne os formulários acessíveis, concisos, resistentes a spam e idempotentes. Conecte a e atribuição ao dinheiro, não a preenchimentos de formulário (references/measurement-and-attribution.md). Bloqueie todas as tags não essenciais atrás do consentimento (references/privacy-and-consent.md).
Portão 5: QA
Execute references/qa-checklist.md: esquema, rotas, links, formulários, analytics, consentimento, indexação, metadados, desempenho (references/performance-gate.md) e acessibilidade. Defina a indexação intencionalmente por variante (references/seo-and-indexation.md).
Portão 6: lançamento e aprendizado
Gere o manifesto da campanha (scripts/generate_campaign_manifest.py) e um
plano de rollback. Lance o conjunto mínimo viável, geralmente 1-2 hipóteses
verdadeiramente diferentes por cluster de intenção, não todos os conceitos. Após o
tráfego, compare a conversão qualificada e a receita downstream, não cliques. Pause
hipóteses fracas; alimente as lições verificadas de volta na matriz e em
experiments/landing-experiments.csv.
Habilidades adjacentes (invocar preguiçosamente, via contratos)
Não carregue toda habilidade para cada tarefa. Passe apenas o que a etapa precisa, para as próprias habilidades instaladas do projeto:
- dores do público e voz do cliente -> a habilidade de pesquisa/contação de histórias do projeto
- modelagem de oferta -> o trabalho de ofertas do projeto
- configuração de campanha e medição ->
paid-ads-launch - SEO e esquema de página indexável ->
seo-optimization - ativos de imagem ->
web-images - blocos de FAQ e objeções ->
faq-hub - nutrição pós-conversão ->
brevo-automation, como um adaptador downstream OPCIONAL apenas; nunca uma dependência rígida, e nunca conectado automaticamente.
Limites de segurança e autoridade
- Nunca coloque chaves de API, tokens de CRM, segredos de pagamento ou conteúdos de
.envem prompts, dados de origem, páginas, logs ou commits. Use placeholders; o usuário insere segredos na interface de serviço confiável. - Não conecte CRM, analytics, autenticação, contas de anúncios, provedores de pagamento ou implante/publique sem permissão explícita para esse serviço e ação.
- Trate pagamentos em produção, lançamento público, ativação de campanha e envio em massa como portões separados de aprovação humana.
- Não prometa alegações não suportadas (tempo de construção fixo, custo, aumento de conversão ou escala ilimitada). Respeite as restrições de alegações regulamentadas do projeto.
- Respeite o estilo da casa do projeto: regras de idioma e bilíngues, sem travessões em cópia pública, cabeçalhos sem ponto final, nenhum traço de ferramenta de IA no código enviado.
Entregáveis
Retorne o menor conjunto útil: matriz de intenções/variantes; contratos de landing; esquema e arquivo de dados validados; um template reutilizável e resolvedor de rota; pré-visualizações representativas; manifesto de campanha/URL; formulário e contrato de e atribuição; mapa de consentimento; resultados de QA; lista de verificação de lançamento/rollback; plano de leitura de experimento. Indique o que foi verificado, o que é assumido e o que ainda precisa de aprovação humana.