Communitygithub.com

marynacleo/build-multilanding

Projete, construa, audite ou dimensione um sistema de landing pages multi-segmento orientado por dados, a partir de um único template da marca, impulsionado pela intenção de busca e um contexto de marketing de projeto validado.

O que é build-multilanding?

Esta skill capacita agentes de IA a projetar, construir e dimensionar um sistema completo de landing pages multi-segmento, mantendo uma única base de código e marca consistente. Ao invés de criar páginas copiadas manualmente, ela trata cada variante como uma hipótese de marketing testável, com sua própria trilha de auditoria desde o clique do anúncio até a receita. A skill é um motor de métodos, contratos e validações que opera em seis portões (gates) — desde a estratégia de intenção de busca até o lançamento e aprendizado — evitando que o agente invente públicos ou ofertas. Ela se integra perfeitamente com o contexto de marketing do projeto (lendo arquivos como `.agents/product-marketing.md`) e oferece scripts para validar entradas, compor páginas modularmente e gerar manifestos de campanha. É ideal para anúncios pagos (Google/Meta/LinkedIn), landing pages personalizadas ou programáticas, e cenários que exigem de algumas a milhares de variantes, sempre respeitando as regras de segurança e autoridade definidas.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add marynacleo/build-multilanding

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

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

  1. Leia .agents/product-marketing.md (fonte estratégica da verdade) através do marketing/source-map.yaml do projeto. Fallback: .claude/product-marketing-context.md.
  2. Leia o briefing da campanha para o lançamento. Carregue apenas as intenções, mensagens, ofertas e provas vinculadas.
  3. Classifique cada fato como confirmado / derivado / hipótese / desconhecido.
  4. 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 .env em 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.

Habilidades Relacionadas