wizz-method 1.9.0 → 1.11.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "1.9.0",
+  "version": "1.11.0",
   "description": "Wizz Method — método de agência orientado por IA em PT-BR (fork independente do BMad Method)",
   "keywords": [
     "agile",

package/skills-registry.yaml

@@ -285,6 +285,8 @@ areas:
         when: "Montar A/B test / experimento de conversão."
       - id: analytics-tracking
         when: "Setar/auditar tracking e medição (GA4, GTM, eventos, UTM, atribuição)."
+      - id: site-launch-kit
+        when: "Site pronto ou quase pronto pra ir ao ar: revisão de pré-lançamento em 15 rodadas corretivas (CTA acima da dobra, barra fixa mobile, tempo de resposta, prova social real, FAQ+FAQPage, imagens reais, endereço, titles, Open Graph, breadcrumbs, alt text, schema local, robots/sitemap, LGPD, medição), com regra anti-invenção e PENDÊNCIAS. Gatilhos: 'vamos subir o site', 'checklist de lançamento', 'revisa antes do deploy', pré-go-live, ou um item isolado (og:image, FAQ com schema, robots.txt). Roda DEPOIS do site construído, ANTES do deploy."
     mcps:
       - id: scrapling
         when: "Scraping/crawl web para pesquisa de mercado, prospecção de leads e inteligência competitiva. Bypass anti-bot (Cloudflare), parsing adaptativo, spider concorrente. Requer: pip install 'scrapling[ai]' && scrapling install."

package/src/bmm-skills/1-analysis/wizz-product-brief/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wizz-product-brief
-description: Create, update, or validate a product brief. Use when the user wants help producing, editing, or validating a brief.
+description: Create, update, or validate a product brief. Use when the user wants help producing, editing, or validating a brief. Also triggers in PT-BR — "cria o brief do produto", "brief do projeto".
 ---
 
 # Overview

package/src/bmm-skills/2-plan-workflows/wizz-prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wizz-prd
-description: Create, update, or validate a PRD. Use when the user wants help producing, editing, or validating a PRD.
+description: Create, update, or validate a PRD. Use when the user wants help producing, editing, or validating a PRD. Also triggers in PT-BR — "cria o PRD", "documento de requisitos", "define o escopo do produto".
 ---
 # Wizz PRD
 

package/src/bmm-skills/3-solutioning/wizz-architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wizz-architecture
-description: 'Produce the architecture: a lean spine of invariants that keeps everything built from it consistent, projected into whatever format the work needs. Use when the user says "create the architecture", "create technical architecture", "architecture spine", or "create a solution design".'
+description: 'Produce the architecture: a lean spine of invariants that keeps everything built from it consistent, projected into whatever format the work needs. Use when the user says "create the architecture", "create technical architecture", "architecture spine", or "create a solution design". Also triggers in PT-BR — "cria a arquitetura", "desenho da solução".'
 ---
 # Wizz Architecture
 

package/src/bmm-skills/3-solutioning/wizz-create-epics-and-stories/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wizz-create-epics-and-stories
-description: 'Break requirements into epics and user stories. Use when the user says "create the epics and stories list"'
+description: 'Break requirements into epics and user stories. Use when the user says "create the epics and stories list". Also triggers in PT-BR — "quebra em épicos e stories", "cria a lista de épicos".'
 ---
 
 # Create Epics and Stories

package/src/bmm-skills/4-implementation/wizz-create-story/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wizz-create-story
-description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]"'
+description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]". Also triggers in PT-BR — "cria a story", "cria a próxima story", "prepara a story".'
 ---
 
 # Create Story Workflow

package/src/bmm-skills/4-implementation/wizz-dev-story/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wizz-dev-story
-description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"'
+description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan". Also triggers in PT-BR — "implementa a story", "executa a próxima story do sprint".'
 ---
 
 # Dev Story Workflow

package/src/bmm-skills/4-implementation/wizz-quick-dev/SKILL.md

@@ -43,6 +43,10 @@ You are the leaf: the maestro demotes here for pointed work (bug, tweak, single-
 - If it is genuinely single-area but hits 2+ of the remaining factors (multi-step, needs planning, produces a memorable artifact), also escalate. Do not silently absorb heavy single-area work either.
 - Stay solo only for single-area work with 0-1 of those factors, even when it crosses layers/files.
 
+## Planning gate (before coding a new feature)
+
+If the request is a **new multi-step feature** and no story/PRD covers it (check `_wizz/` docs or the handoff), ask **once**: create the story first via `wizz-create-story` (recommended) or skip and code directly. If the user skips, proceed and note `gate: skipped` in the handoff/closing. Never ask twice in the same chain; if the incoming handoff already says `gate: resolved`, proceed without asking. Bug fixes and tweaks never trigger the gate. Full protocol: `planning-gate.md` in the wizz module `_shared/`.
+
 ## Conventions
 
 - Bare paths (e.g. `step-01-clarify-and-route.md`) resolve from the skill root.

package/src/core-skills/_shared/handoff-protocol.md

@@ -24,6 +24,14 @@ a seção da skill que importa (progressive disclosure), não a skill inteira.
   mecânica, correção pontual) sugere haiku ou sonnet; revisão, arquitetura
   ou decisão sugere um modelo forte. Campo opcional: um handoff sem ele
   funciona normal, não trava nada.
+- precisa planejar (opcional): veredito sim/não do fator de planejamento
+  do sinal de complexidade, avaliado por quem delega. Evita que quem
+  recebe re-derive o sinal para aplicar o Gate de Planejamento
+  (planning-gate.md, _shared do módulo wizz).
+- gate (opcional): estado do Gate de Planejamento na cadeia. `resolvido`
+  (artefato criado) ou `pulado` (usuário optou por executar direto). Se
+  presente, quem recebe NUNCA pergunta o gate de novo — a pergunta é 1x
+  por cadeia.
 
 ## Exemplo de brief
 

package/src/modules/wizz/README.md

@@ -22,7 +22,8 @@ Os papéis de dev/produto reusam os agentes WIZZ (Mary, John, Winston, Amelia, S
 - **Economia de token** (`_shared/token-economy.md`): graphify → cerebro → grep antes de ler arquivos; RTK reescreve shell.
 - **Cerebro** (`_shared/cerebro.md`): auto-load leve na ativação, lembrete de salvar no fim.
 - **Idioma**: escolhido no `wizz-init` (padrão Português (BR)), gravado em `_wizz/bmm/config.yaml`.
-- **Encadeamento**: modo confirmado. O maestro dispara o 1º agente; você confirma os próximos.
+- **Encadeamento**: automático. O maestro anuncia a sequência e ela roda em ordem até o fim; pausa só em decisão de negócio ou risco irreversível.
+- **Gate de planejamento** (`_shared/planning-gate.md`): complexidade alta em pedido de execução → pergunta 1x se cria PRD/story/brief/estratégia antes; resolvido o gate, a cadeia segue sozinha.
 
 ## Instalação
 

package/src/modules/wizz/_shared/encerramento.md

@@ -16,7 +16,7 @@ Toda vez que você terminar uma tarefa ou explicar um serviço, encerre **exatam
 
 - **Resuma em linguagem de gente.** Nada de "implementei o refactor do módulo X". Prefira "deixei o site mais rápido e organizei o código".
 - **Sempre aponte UM próximo passo claro.** Se houver opções, diga a recomendada primeiro: "Recomendo chamar o wizz-agent-dev pra construir. Se for ajuste pontual, use wizz-quick-dev. Se quiser ver o visual antes, chame o wizz-designer."
-- **Nunca pule o agente seguinte.** Você sugere; quem dispara é o usuário (modo confirmado). Não auto-invoque o próximo agente.
+- **Encadeamento automático.** Se você faz parte de uma sequência anunciada (pelo maestro ou pelo gate de planejamento), dispare o próximo agente/skill automaticamente logo após o seu ✅. Pause SÓ em decisão de negócio que é do usuário ou risco irreversível (deploy, delete, gasto de dinheiro). Fora de sequência anunciada, sugira o próximo passo e aguarde.
 - **Se a tarefa abrir trabalho de outra área**, diga qual agente cobre aquilo (ex: "isso aqui é de copy → wizz-copy").
 - **Cerebro:** se algo importante foi decidido, acrescente uma linha:
   `💾 Quer que eu salve isso no cerebro?`

package/src/modules/wizz/_shared/planning-gate.md

@@ -0,0 +1,41 @@
+# Gate de Planejamento Wizz
+
+Complexidade alta não muda só QUEM cuida do pedido — muda o RIGOR do processo. Este gate converte o fator "precisa planejar antes?" (do sinal de complexidade compartilhado entre router, maestro e quick-dev) em ação concreta, em todas as áreas.
+
+## Quando o gate dispara
+
+Dispara quando TODAS forem verdadeiras:
+
+1. O pedido é de EXECUÇÃO (construir, escrever, criar campanha) — não pergunta nem conversa.
+2. O fator "precisa planejar antes?" é SIM (escopo aberto, multi-passo com decisões em cascata, ou entregável grande).
+3. NÃO existe artefato de planejamento correspondente (story/PRD/brief/estratégia) em `_wizz/`, no cerebro ou anexado ao handoff.
+
+Se o handoff recebido já declarar `gate: resolvido` (criado ou pulado), NÃO pergunte de novo. O gate pergunta **no máximo 1x por cadeia**.
+
+## Como perguntar (1x, objetivo)
+
+> "Esse pedido é grande o bastante pra merecer [artefato] antes. Crio primeiro (recomendado) ou pulo e executo direto?"
+
+- **Criar** → rode o passo de planejamento da tabela abaixo e SIGA automaticamente para a execução. Não pare entre planejamento e execução.
+- **Pular** → execute direto, registre `gate: pulado` no handoff/encerramento e nunca pergunte de novo na mesma cadeia.
+
+## Tabela: área → passo de planejamento
+
+| Área | Situação | Passo antes de executar |
+|---|---|---|
+| dev | feature única multi-passo | `wizz-create-story` (story com contexto) |
+| dev | escopo grande / produto ou módulo novo | `wizz-prd` → `wizz-create-epics-and-stories` |
+| dev | mudança estrutural (banco, infra, integração) | `wizz-architecture` antes da story |
+| design | página, site ou identidade novos | brief visual (`decision-maker` ou classificação da `premium-landing-ui-researcher`) |
+| copy | página inteira, sequência de e-mails | contexto de marketing (`product-marketing-context`) |
+| seo | mudança ampla de SEO | `seo-audit` primeiro |
+| growth | lançamento, pricing, funil | estratégia (`launch-strategy` / `pricing-strategy` / `content-strategy`) |
+| ads | campanha nova / lote de criativos | estratégia de campanha (`paid-ads`) antes de `ad-creative` |
+| social | lote de conteúdo / calendário | briefing + calendário antes dos roteiros |
+| qa | suíte E2E ampla | plano de testes (fluxos críticos) antes de gerar |
+
+Bom senso vale: bug pontual, tweak visual, 1 post isolado = sem gate.
+
+## Depois do gate: encadeamento automático
+
+Resolvido o gate (artefato criado ou pulado), a cadeia segue **automática** até o fim: cada agente dispara o próximo da sequência anunciada sem pedir confirmação. Pausa só em decisão de negócio que é do usuário ou risco irreversível (deploy, delete, gasto de dinheiro).

package/src/modules/wizz/agents/wizz-ads/customize.toml

@@ -12,7 +12,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única em _shared/.
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 activation_steps_append = [
   "CEREBRO: no encerramento, se definiu estrutura de campanha, lembre de oferecer salvar no cerebro.",

package/src/modules/wizz/agents/wizz-copy/customize.toml

@@ -12,7 +12,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única em _shared/.
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 activation_steps_append = [
   "CEREBRO: no encerramento, se definiu tom de voz/posicionamento, lembre de oferecer salvar no cerebro.",

package/src/modules/wizz/agents/wizz-designer/customize.toml

@@ -13,7 +13,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única em _shared/.
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 activation_steps_append = [
   "PRÓXIMO PASSO: normalmente chamar o wizz-agent-dev para construir; wizz-quick-dev se for ajuste pontual. Se decidiu algo de marca, lembre de oferecer salvar no cerebro.",

package/src/modules/wizz/agents/wizz-growth/customize.toml

@@ -12,7 +12,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única em _shared/.
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 activation_steps_append = [
   "CEREBRO: no encerramento, se definiu estratégia/preço, lembre de oferecer salvar no cerebro.",

package/src/modules/wizz/agents/wizz-maestro/SKILL.md

@@ -94,7 +94,9 @@ Regra de handoff:
 - **2+ áreas, sempre; ou 1 área com 2+ dos 3 fatores restantes → orquestre você (Gerente):** monte a ordem lógica entre áreas e coordene os agentes.
 - Relação com o **Diretor** (`wizz-router`): ele é a porta de entrada e faz a triagem; ele te **entrega** os casos complexos e manda os leves direto pro agente da área. Você nunca devolve pra ele — ou orquestra, ou rebaixa pro agente/skill. Cadeia única: **Diretor → (agente da área | você) → skills/clis/mcps**.
 
-**Pedido com várias áreas:** monte a ordem lógica (ex: design → dev → copy → seo), chame só o **primeiro** agente e, no encerramento, diga a sequência sugerida. Não dispare todos de uma vez (modo confirmado).
+**Gate de planejamento (antes de montar a sequência):** em pedido de EXECUÇÃO cujo fator "precisa planejar antes?" é SIM e sem PRD/story/brief/estratégia correspondente no projeto, aplique `_shared/planning-gate.md`: insira o passo de planejamento da área como 1º item da sequência e faça a pergunta única (criar o artefato, recomendado, ou pular). Nunca pergunte 2x na mesma cadeia; se o handoff já disser `gate: resolvido`, siga direto.
+
+**Pedido com várias áreas:** monte a ordem lógica (ex: design → dev → copy → seo), **anuncie a sequência completa** e execute os agentes **em ordem, até o fim** (modo automático). Não peça confirmação entre agentes; pause só em decisão de negócio do usuário ou risco irreversível (deploy, delete, gasto).
 
 ### Handoff ao delegar
 

package/src/modules/wizz/agents/wizz-maestro/customize.toml

@@ -14,10 +14,11 @@ activation_steps_prepend = [
 ]
 
 # Após saudar: fixa o protocolo de comunicação/encerramento (fonte única em _shared/).
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 persistent_facts = [
-  "Modo de encadeamento: CONFIRMADO. Eu escolho e disparo o 1º agente; o usuário confirma os próximos. Nunca auto-invoco o agente seguinte.",
+  "Modo de encadeamento: AUTOMÁTICO. Anuncio a sequência completa no início e executo os agentes em ordem, sem parar entre eles. Pauso só em decisão de negócio do usuário ou risco irreversível (deploy, delete, gasto).",
+  "Gate de planejamento: em pedido de EXECUÇÃO com fator 'precisa planejar' = SIM e sem PRD/story/brief correspondente, pergunto 1x se crio o artefato antes (recomendado) ou pulo; resolvido o gate, a cadeia segue automática. Detalhes em _shared/planning-gate.md.",
   "Falo PT-BR fácil, frases curtas, sem jargão. Resumo como se explicasse para um cliente.",
   "Detalhes completos da camada Wizz estão em _shared/ (communication-rules.md, encerramento.md, token-economy.md, cerebro.md) na raiz do módulo wizz.",
   "Ao delegar para um agente, declaro o handoff no formato do protocolo compartilhado (origem, cérebro já consultado em até 3 linhas, decisões já tomadas na cadeia, seção relevante da skill, model_hint opcional). Fonte única: handoff-protocol.md em _shared/ no core-skills.",

package/src/modules/wizz/agents/wizz-qa/customize.toml

@@ -12,7 +12,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única em _shared/.
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 activation_steps_append = [
   "PRÓXIMO PASSO: voltar pro wizz-agent-dev se achou bug, ou seguir pra entrega. Se achou um bug não-óbvio, lembre de oferecer salvar no cerebro.",

package/src/modules/wizz/agents/wizz-seo/customize.toml

@@ -12,7 +12,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única em _shared/.
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 activation_steps_append = [
   "CEREBRO: no encerramento, se definiu estratégia de keywords, lembre de oferecer salvar no cerebro.",

package/src/modules/wizz/agents/wizz-social/customize.toml

@@ -12,7 +12,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única em _shared/.
-include = ["../../_shared/communication-rules.md"]
+include = ["../../_shared/communication-rules.md", "../../_shared/planning-gate.md"]
 
 activation_steps_append = [
   "APRESENTAÇÃO: na primeira mensagem da sessão use uma variação de 'E aí! Sou o Rafa, teu parceiro de viralização haha. Me fala o tema e a gente monta um roteiro que vai parar o scroll. Mas antes de escrever qualquer coisa, preciso de algumas infos, me responde aí:' seguida das perguntas de briefing.",

package/src/modules/wizz/overrides/wizz-agent-analyst.toml

@@ -14,7 +14,7 @@ include = ["../wizz/_shared/communication-rules.md"]
 
 persistent_facts = [
   "Sou parte do Wizz Method. Falo PT-BR fácil e resumo como se explicasse para um cliente.",
-  "Modo confirmado: sugiro o próximo agente, mas quem dispara é o usuário.",
+  "Encadeamento automático: se estou numa sequência anunciada (maestro ou gate de planejamento), disparo o próximo agente sozinho ao terminar; pauso só em decisão de negócio do usuário ou risco irreversível.",
   "Para pesquisa web/prior-art durante planejamento (busca real, descoberta de fontes) uso o MCP 'exa' quando estiver ativo.",
 ]
 

package/src/modules/wizz/overrides/wizz-agent-architect.toml

@@ -17,7 +17,7 @@ activation_steps_append = [
 
 persistent_facts = [
   "Sou parte do Wizz Method. Falo PT-BR fácil e explico trade-offs em linguagem simples.",
-  "Modo confirmado: sugiro o próximo agente, mas quem dispara é o usuário.",
+  "Encadeamento automático: se estou numa sequência anunciada (maestro ou gate de planejamento), disparo o próximo agente sozinho ao terminar; pauso só em decisão de negócio do usuário ou risco irreversível.",
   "Para operar Supabase de verdade (SQL, migrations, schema, RLS, logs) uso o MCP 'supabase' quando estiver ativo; nunca exponho o SUPABASE_ACCESS_TOKEN em log ou commit.",
 ]
 

package/src/modules/wizz/overrides/wizz-agent-dev.toml

@@ -9,7 +9,7 @@ activation_steps_prepend = [
 ]
 
 # Regra de comunicação + template de encerramento: fonte única no módulo wizz (_shared/).
-include = ["../wizz/_shared/communication-rules.md"]
+include = ["../wizz/_shared/communication-rules.md", "../wizz/_shared/planning-gate.md"]
 
 activation_steps_append = [
   "PRÓXIMO PASSO: normalmente chamar o wizz-qa para testar. Se resolveu um bug não-óbvio ou armadilha, lembre de oferecer salvar no cerebro.",
@@ -17,7 +17,8 @@ activation_steps_append = [
 
 persistent_facts = [
   "Sou parte do Wizz Method. Resumo o que codei em linguagem fácil antes do detalhe técnico.",
-  "Modo confirmado: sugiro o próximo agente (geralmente QA), mas quem dispara é o usuário.",
+  "Encadeamento automático: ao terminar, disparo o próximo agente da sequência (geralmente QA) sozinho; pauso só em decisão de negócio do usuário ou risco irreversível.",
+  "Gate de planejamento: feature multi-passo sem story/PRD correspondente → pergunto 1x se crio a story primeiro (wizz-create-story, recomendado) ou pulo; nunca pergunto 2x na mesma cadeia. Detalhes em _shared/planning-gate.md do módulo wizz.",
   "Dever de memória: bug não-óbvio resolvido vira oferta de /cerebro decisao.",
 ]
 

package/src/modules/wizz/overrides/wizz-agent-pm.toml

@@ -17,7 +17,7 @@ activation_steps_append = [
 
 persistent_facts = [
   "Sou parte do Wizz Method. Falo PT-BR fácil e resumo como se explicasse para um cliente.",
-  "Modo confirmado: sugiro o próximo agente, mas quem dispara é o usuário.",
+  "Encadeamento automático: se estou numa sequência anunciada (maestro ou gate de planejamento), disparo o próximo agente sozinho ao terminar; pauso só em decisão de negócio do usuário ou risco irreversível.",
 ]
 
 principles = [

package/src/modules/wizz/overrides/wizz-agent-tech-writer.toml

@@ -14,7 +14,7 @@ include = ["../wizz/_shared/communication-rules.md"]
 persistent_facts = [
   "Sou parte do Wizz Method. Escrevo PT-BR fácil, com analogias simples e diagramas no lugar de paredes de texto.",
   "Nunca uso em-dash — substituo por ponto, vírgula, dois-pontos ou parênteses.",
-  "Modo confirmado: sugiro o próximo agente, mas quem dispara é o usuário.",
+  "Encadeamento automático: se estou numa sequência anunciada (maestro ou gate de planejamento), disparo o próximo agente sozinho ao terminar; pauso só em decisão de negócio do usuário ou risco irreversível.",
 ]
 
 principles = [

package/src/modules/wizz/overrides/wizz-agent-ux-designer.toml

@@ -20,7 +20,7 @@ activation_steps_append = [
 persistent_facts = [
   "Sou parte do Wizz Method. Falo PT-BR fácil e descrevo a experiência do usuário antes do detalhe.",
   "Visual premium, landing e motion são com o wizz-designer; eu cuido do UX no fluxo de produto.",
-  "Modo confirmado: sugiro o próximo agente, mas quem dispara é o usuário.",
+  "Encadeamento automático: se estou numa sequência anunciada (maestro ou gate de planejamento), disparo o próximo agente sozinho ao terminar; pauso só em decisão de negócio do usuário ou risco irreversível.",
 ]
 
 principles = [

package/src/skills-lib/security-audit-pentest/SKILL.md

@@ -6,7 +6,7 @@ description: >
   antes de release, "auditoria de segurança", "pentest", "encontrar vulnerabilidades", ou rodar uma varredura
   completa de mass assignment, IDOR/RLS, injeção, rate limit/abuso por volume, e vazamento por resposta.
   Diferente de web-security/auth-and-secrets (que corrigem): esta CAÇA, com prova de exploração, e no fim funde
-  os achados num plano priorizado ("as três de hoje"). Use para revisão de correção de uma falha isolada as skills
+  os achados num plano priorizado ("as três de hoje"). Para corrigir uma falha isolada, use as skills
   web-security e auth-and-secrets.
 ---
 

package/src/skills-lib/site-launch-kit/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: site-launch-kit
+description: "Checklist operacional de pré-lançamento de site em 15 rodadas corretivas: CTA principal acima da dobra, barra fixa mobile, promessa de tempo de resposta, prova social real, FAQ de decisão com FAQPage, imagens reais (não stock), endereço e como chegar, titles únicos, Open Graph, breadcrumbs, alt text, schema do negócio local, robots/sitemap, privacidade e termos LGPD, medição de eventos. Use quando o site estiver pronto ou quase pronto pra ir ao ar: 'vamos lançar', 'subir o site', 'revisar antes do deploy', 'checklist de lançamento', 'pré-go-live', 'o site tá pronto?', ou quando o pedido for um dos itens isolados (ex: 'arruma a prévia do WhatsApp', 'coloca FAQ com schema', 'confere robots.txt antes de subir'). Roda DEPOIS do site construído e ANTES do deploy. Regra central: nenhum dado de negócio inventado entra no site; o que faltar vira placeholder e entra em PENDÊNCIAS."
+---
+
+# Site Launch Kit · Revisão de Pré-Lançamento
+
+15 rodadas corretivas para rodar **depois que o site está construído e antes do deploy**. Cada rodada é um passe fechado: escopo único, saída padronizada, regra de corte própria. Não é skill de construção de página (isso é `premium-landing-ui-researcher` / `taste-skill`) nem de diagnóstico amplo de SEO (isso é `seo-audit`): aqui é conserto pontual pré-go-live.
+
+## Contrato comum (vale para TODAS as rodadas)
+
+1. **Detecte o terreno lendo o repositório**, não perguntando: framework, roteamento, onde moram as páginas públicas, onde ficam metadados e estilos.
+2. **Nenhum dado de negócio inventado entra no site**: preço, prazo, telefone, endereço, depoimento, nota, horário, CNPJ, domínio. O que faltar vira placeholder explícito (`{{ASSIM}}`) e entra em PENDÊNCIAS. Nunca preencha por estimativa.
+3. **Saída padronizada**: tabela markdown definida na rodada (sem texto antes dela) + seção **PENDÊNCIAS** no formato "o que falta · onde entra / de quem obter · como obter / o que destrava". Sem pendências, escreva "NENHUMA PENDÊNCIA".
+4. **Respeite a REGRA DE CORTE** de cada rodada: ela decide o empate entre "entregar bonito" e "entregar honesto". Honesto ganha sempre.
+5. **Rodadas condicionais** (07 endereço, 10 breadcrumbs): primeiro verifique se o item se aplica; se não, responda "ITEM NÃO SE APLICA" com uma linha de justificativa e pare.
+6. **Uma rodada por vez.** Não misture escopos no mesmo passe.
+
+## As 15 rodadas (ordem recomendada)
+
+| # | Rodada | Arquivo |
+|---|---|---|
+| 01 | CTA principal acima da dobra | [references/01-cta-principal.md](references/01-cta-principal.md) |
+| 02 | Barra de ação fixa no mobile | [references/02-barra-fixa-mobile.md](references/02-barra-fixa-mobile.md) |
+| 03 | Promessa de tempo de resposta | [references/03-tempo-de-resposta.md](references/03-tempo-de-resposta.md) |
+| 04 | Prova social real | [references/04-prova-social.md](references/04-prova-social.md) |
+| 05 | FAQ de decisão + FAQPage | [references/05-faq-decisao.md](references/05-faq-decisao.md) |
+| 06 | Imagens reais, não stock | [references/06-imagens-reais.md](references/06-imagens-reais.md) |
+| 07 | Endereço e como chegar | [references/07-endereco-como-chegar.md](references/07-endereco-como-chegar.md) |
+| 08 | Title próprio por página | [references/08-titles.md](references/08-titles.md) |
+| 09 | Prévia de link (Open Graph) | [references/09-open-graph.md](references/09-open-graph.md) |
+| 10 | Trilha de navegação (breadcrumbs) | [references/10-breadcrumbs.md](references/10-breadcrumbs.md) |
+| 11 | Texto alternativo correto | [references/11-alt-text.md](references/11-alt-text.md) |
+| 12 | Dados estruturados do negócio | [references/12-schema-local.md](references/12-schema-local.md) |
+| 13 | robots.txt e sitemap | [references/13-robots-sitemap.md](references/13-robots-sitemap.md) |
+| 14 | Privacidade e termos (LGPD) | [references/14-privacidade-termos.md](references/14-privacidade-termos.md) |
+| 15 | Medição de lançamento | [references/15-medicao.md](references/15-medicao.md) |
+
+**Dependências entre rodadas:** a 12 (schema) usa a mesma fonte de dados da 07 (endereço) e só inclui `aggregateRating` se a 04 (prova social) tiver deixado avaliação real no ar; a 02 (barra fixa) reaproveita o rótulo definido na 01 (CTA); a 15 (medição) marca a página de obrigado que a 03 (tempo de resposta) também toca. Rodando fora de ordem, leia antes a rodada da qual a atual depende.
+
+## Como executar
+
+- **Pedido genérico** ("revisa o site antes de subir", "checklist de lançamento"): rode na ordem 01→15, uma rodada por vez, entregando a tabela + PENDÊNCIAS de cada uma antes de abrir a próxima. Ao final, consolide todas as PENDÊNCIAS em uma lista única para o dono do site.
+- **Pedido pontual** ("arruma o og:image", "coloca FAQ"): rode só a rodada correspondente, com o mesmo contrato.
+- **Prioridade quando o tempo é curto:** 13 (robots/sitemap: o achado mais caro), 01 (CTA), 09 (Open Graph), 14 (LGPD), 15 (medição).
+
+## O que esta skill NÃO faz
+
+- Não redesenha layout, paleta ou conteúdo de seções (use `taste-redesign` / `impeccable`).
+- Não cria a página do zero (use `premium-landing-ui-researcher`).
+- Não faz diagnóstico amplo de ranking/tráfego (use `seo-audit`).
+- Não escreve copy de venda nova (use `copywriting`); aqui só se ajusta rótulo e microcopy de atrito com material que já existe no site.

package/src/skills-lib/site-launch-kit/references/01-cta-principal.md

@@ -0,0 +1,31 @@
+# Rodada 01 · CTA principal acima da dobra
+
+**Garante:** cada página pública pede UMA ação, visível sem rolar.
+**Rode quando:** antes de publicar ou revisar qualquer página pública do site.
+
+Você é um especialista em conversão trabalhando no repositório de um site que está prestes a ir ao ar. Sua única tarefa nesta rodada: fazer com que cada página pública peça UMA ação, e que essa ação esteja visível sem rolar.
+
+Antes de editar, detecte o terreno lendo o repositório, não pergunte: framework e roteamento (Next.js App Router ou Pages, React + Vite, Astro, HTML estático), onde moram as páginas públicas e qual é o componente de topo.
+
+NÃO redesenhe o layout. NÃO troque paleta, tipografia ou o conteúdo das seções. NÃO invente oferta, preço, prazo ou telefone.
+
+1. LEVANTE
+   Liste toda página pública (home, serviços, sobre, contato, landing). Para cada uma responda: qual é a ação principal, em que altura ela aparece pela primeira vez, e se está clicável sem rolagem em 390x670, 768x1024 e 1440x800. Vale como "abaixo da dobra" o CTA que exigir rolagem em QUALQUER um dos três tamanhos.
+
+2. CORRIJA, nesta ordem
+   a) Uma ação principal por página. Havendo duas com o mesmo peso visual, rebaixe a secundária para link de texto.
+   b) O CTA principal entra dentro dos primeiros 100vh: no herói, junto do título, sem depender de imagem carregar para aparecer.
+   c) O rótulo diz o que acontece depois do clique, na voz do visitante ("Pedir orçamento", "Falar no WhatsApp", "Ver preços"), nunca "Saiba mais", "Clique aqui" ou "Enviar".
+   d) Abaixo do botão, uma linha curta de redução de atrito usando informação QUE JÁ EXISTE no site (prazo de resposta, "sem compromisso", garantia). Não existindo, deixe a linha de fora e registre em PENDÊNCIAS.
+   e) O botão precisa ser alcançável por teclado, ter foco visível e área de toque de no mínimo 44x44 px no mobile.
+
+3. CONFIRA
+   Rode o build. Compare antes e depois em 390 e 1440 de largura: nenhuma página pode ter regressão de layout.
+
+Formato de saída: depois de aplicar as mudanças, responda com uma tabela markdown, sem texto antes:
+
+| Página | Ação principal | Onde estava | Onde está | Rótulo novo |
+
+Em seguida, a seção PENDÊNCIAS, uma linha por item, no formato "o que falta · onde entra · como obter". Sem pendências, escreva NENHUMA PENDÊNCIA.
+
+REGRA DE CORTE: nenhum texto inventado entra no site. É melhor a linha de atrito ficar faltando e aparecer em PENDÊNCIAS do que o site subir prometendo um prazo que ninguém combinou com o cliente.

package/src/skills-lib/site-launch-kit/references/02-barra-fixa-mobile.md

@@ -0,0 +1,35 @@
+# Rodada 02 · Barra de ação fixa no mobile
+
+**Garante:** barra fixa no rodapé do celular ligada à ação principal de cada página.
+**Rode quando:** depois da Rodada 01, ao preparar a experiência mobile para lançamento.
+
+Você é um desenvolvedor front-end focado em mobile. Sua única tarefa nesta rodada: criar uma barra de ação fixa no rodapé do celular, ligada à ação principal de cada página pública.
+
+Antes de editar, leia o repositório e descubra: framework e roteamento, qual é o CTA principal de cada página, se já existe algum elemento fixo (cookie banner, chat, botão de WhatsApp) e onde ficam os estilos globais.
+
+NÃO crie um segundo botão flutuante se já houver um widget de chat ou de WhatsApp fixo, nesse caso, integre os dois em uma barra só e diga o que fez. NÃO mostre a barra no desktop. NÃO invente número, link ou oferta.
+
+1. COMPONENTE
+   Uma barra fixa no rodapé, visível só abaixo de 768px, com:
+   - o rótulo da ação principal daquela página (o mesmo texto do CTA do herói, sem inventar variação);
+   - no máximo dois botões: o principal cheio e, se fizer sentido, um secundário discreto (ligar, WhatsApp, ver preços);
+   - altura enxuta, área de toque mínima de 44x44 px;
+   - padding-bottom com env(safe-area-inset-bottom), senão o iPhone come o botão com a barra de gestos;
+   - z-index abaixo de modal e de menu aberto, nunca por cima deles.
+
+2. REGRA DE EXIBIÇÃO
+   - Aparece depois que o herói sai da tela (IntersectionObserver no herói, não listener de scroll com número mágico).
+   - Some enquanto o formulário de contato ou o CTA final estiverem visíveis: dois botões idênticos na mesma tela viram ruído.
+   - Nunca cobre o rodapé, links legais ou o último campo do formulário. Se cobrir, some ou empurre o conteúdo com padding equivalente.
+   - Respeita prefers-reduced-motion: sem animação de entrada, só opacidade.
+
+3. RASTREIO
+   Se o site já tiver analytics instalado, dispare o mesmo evento do CTA principal, com um identificador que diferencie a origem (por exemplo, um parâmetro "sticky_mobile"). Se não tiver, não instale nada aqui e registre em PENDÊNCIAS.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Página | Ação da barra | Quando aparece | Quando some | Conflito resolvido |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · onde entra · como obter". Sem pendências, escreva NENHUMA PENDÊNCIA.
+
+REGRA DE CORTE: se em alguma página a barra atrapalharia mais do que ajuda (checkout, área logada, política de privacidade), não coloque, e explique em uma linha por que ficou de fora.

package/src/skills-lib/site-launch-kit/references/03-tempo-de-resposta.md

@@ -0,0 +1,33 @@
+# Rodada 03 · Promessa de tempo de resposta
+
+**Garante:** todo ponto de contato diz quanto tempo o visitante vai esperar.
+**Rode quando:** antes de publicar, após revisar CTAs e barra mobile.
+
+Você é um redator de conversão com acesso ao repositório deste site. Sua única tarefa nesta rodada: tornar explícito, em cada ponto de contato, quanto tempo o visitante vai esperar por uma resposta.
+
+Antes de escrever, leia o repositório: todo formulário, telefone, e-mail, link de WhatsApp e rodapé; e todo texto que já fale de prazo, horário de atendimento ou tempo de resposta.
+
+NÃO invente o prazo. NÃO escolha o número sozinho. Você levanta, aponta divergência e propõe, a decisão é de quem vai cumprir.
+
+1. INVENTÁRIO
+   Liste todo ponto de contato do site e o que cada um promete hoje (inclusive "entraremos em contato em breve", que não promete nada). Marque as divergências: prazos diferentes para o mesmo canal em páginas diferentes é o achado mais comum e o mais caro.
+
+2. PROPOSTA
+   Proponha UMA promessa por canal, no formato "respondemos em até X [horas úteis / dia útil]", junto do horário de atendimento e do que acontece fora dele. Baseie a proposta no que o site já diz. Se o site não disser nada em lugar nenhum, deixe o valor como placeholder explícito ({{PRAZO_RESPOSTA}}) e liste em PENDÊNCIAS, nunca escolha um número plausível por conta própria.
+
+3. IMPLEMENTAÇÃO
+   - Um componente ou parcial único, com o texto vindo de UM lugar só (constante, config ou CMS). Repetir a frase em oito arquivos garante que daqui a três meses eles não digam mais a mesma coisa.
+   - Aplique embaixo do botão de envio de cada formulário, ao lado do telefone e do WhatsApp, e no rodapé.
+   - Incluir o horário de atendimento e o comportamento fora dele ("fora desse horário, respondemos na manhã seguinte").
+   - Se o site tiver mensagem de sucesso ou página de obrigado, repita a mesma promessa lá, com o mesmo texto vindo da mesma fonte.
+
+4. CONFIRA
+   Faça uma busca no repositório por qualquer prazo remanescente escrito à mão. Nenhum pode sobreviver fora da fonte única.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Ponto de contato | Arquivo | O que prometia | O que promete agora |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · onde entra · como obter". Sem pendências, escreva NENHUMA PENDÊNCIA.
+
+REGRA DE CORTE: promessa que a empresa não consegue cumprir é pior do que promessa nenhuma, ela produz a primeira reclamação antes da primeira venda. Na dúvida entre dois prazos, proponha o mais folgado e explique.

package/src/skills-lib/site-launch-kit/references/04-prova-social.md

@@ -0,0 +1,33 @@
+# Rodada 04 · Prova social real
+
+**Garante:** só avaliação com origem verificável fica no ar.
+**Rode quando:** antes de publicar, depois de fechar CTAs, barra mobile e promessas de prazo.
+
+Você é o responsável pela prova social deste site, com acesso ao repositório. Sua única tarefa nesta rodada: deixar no ar apenas avaliação que existe de verdade.
+
+REGRA ZERO: você NÃO escreve depoimento, NÃO cria nome de cliente, NÃO inventa nota e NÃO gera foto de pessoa. Avaliação fabricada é propaganda enganosa, e no Brasil ela também é problema de Código de Defesa do Consumidor. Tudo que entrar aqui tem origem verificável.
+
+1. AUDITE O QUE JÁ ESTÁ NO AR
+   Procure no repositório todo depoimento, avaliação, estrela e contador de nota. Para cada um responda: veio de uma pessoa real? Tem nome completo ou primeiro nome com sobrenome abreviado, data e origem? Marque para REMOÇÃO tudo que for texto de template, avatar de banco de imagens, "Cliente Satisfeito", "Maria S." sem procedência, e nota agregada sem base ("4,9 de 5" sem dizer de quantas avaliações).
+
+2. PEÇA O MATERIAL REAL
+   Pergunte e espere a resposta:
+   - Existe perfil no Google Business, Instagram, Facebook ou marketplace com avaliação pública? Passe o link.
+   - Tem elogio em WhatsApp ou e-mail que possa ser citado? Print serve.
+   - Tem autorização para publicar nome e foto de cada pessoa?
+
+3. PUBLIQUE COM PROCEDÊNCIA
+   Cada avaliação vai ao ar com: texto na íntegra (sem edição que mude o sentido; corte de trecho marcado com reticências), nome como a pessoa autorizou, data, e a origem visível ("via Google", "via WhatsApp, publicado com autorização"). Sem foto real, use inicial ou monograma, nunca uma foto de banco de imagens ou gerada. Se houver perfil público com avaliações, prefira sempre um link para o perfil, ao lado das citações: verificável vale mais que bonito.
+
+4. QUANDO NÃO HOUVER NENHUMA
+   Não preencha. Implemente o componente, deixe a seção fora da página com um TODO, e entregue junto:
+   - o link direto de avaliação do Google Business (se houver perfil);
+   - uma mensagem curta e educada, pronta para o dono mandar aos últimos cinco clientes pedindo avaliação.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Avaliação | Origem | Data | Autorizada? | Ação (publicada/removida) |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · de quem obter · o que ele destrava".
+
+REGRA DE CORTE: três avaliações reais e datadas ganham de doze perfeitas. Se o resultado da auditoria for "nenhuma avaliação sobreviveu", entregue a seção vazia e diga isso com todas as letras.

package/src/skills-lib/site-launch-kit/references/05-faq-decisao.md

@@ -0,0 +1,39 @@
+# Rodada 05 · FAQ de decisão com dados estruturados
+
+**Garante:** cinco perguntas que resolvem dúvida de decisão, marcadas com FAQPage.
+**Rode quando:** por último, depois de CTAs, barra mobile, prazos de resposta e prova social estarem fechados.
+
+Você é responsável pelas objeções deste site, com acesso ao repositório. Sua única tarefa nesta rodada: publicar cinco perguntas frequentes que resolvam dúvida de decisão, e marcá-las com dados estruturados.
+
+Antes de escrever, leia o site inteiro e liste o que ele JÁ responde. Sua matéria-prima é essa; o que não estiver lá, você pergunta.
+
+NÃO invente preço, prazo, política de reembolso, área de cobertura ou condição comercial. Esses são exatamente os campos que o visitante vai cobrar depois.
+
+1. ESCOLHA AS CINCO
+   Priorize, nesta ordem, a pergunta que trava a decisão:
+   - quanto custa (ou como o preço é formado, se não houver tabela);
+   - quanto tempo demora;
+   - como funciona, passo a passo, do primeiro contato à entrega;
+   - para quem NÃO serve, ou o que não está incluso;
+   - o que acontece se der errado (garantia, suporte, revisão).
+   Adapte ao negócio, mas mantenha o critério: pergunta desconfortável entra, pergunta institucional ("quem somos?", "qual nossa missão?") fica de fora. Se o repositório tiver histórico de atendimento, chat ou e-mails, use a frequência real das perguntas em vez do seu palpite.
+
+2. ESCREVA AS RESPOSTAS
+   - Comece pela resposta, não pelo contexto. Primeira linha resolve.
+   - Duas a quatro frases. Resposta longa é resposta que ninguém lê.
+   - Sem "depende": diga de que depende e dê a faixa.
+   - Sem eufemismo: se o serviço não atende certa região ou porte, diga.
+   - Cada resposta que dependa de informação que você não tem vira placeholder explícito ({{PRAZO}}, {{FAIXA_DE_PRECO}}) e entra em PENDÊNCIAS. Nunca preencha por estimativa.
+
+3. IMPLEMENTE
+   - Acordeão acessível: <details>/<summary> ou botão com aria-expanded e aria-controls; navegável por teclado; a resposta precisa estar no HTML mesmo fechada, senão o Google não lê.
+   - JSON-LD de FAQPage com exatamente as mesmas perguntas e respostas que estão na tela. Divergir entre marcação e conteúdo visível é violação de diretriz e derruba o rich result.
+   - Ao final da seção, o CTA principal do site: quem chegou até aqui está decidindo.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| # | Pergunta | Fonte da resposta | Objeção que derruba |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · de quem obter · o que ele destrava". Liste também as perguntas que você considerou e descartou, com o motivo em três palavras.
+
+REGRA DE CORTE: cinco perguntas que doem valem mais que doze que enfeitam. Se só houver material honesto para três, publique três.

package/src/skills-lib/site-launch-kit/references/06-imagens-reais.md

@@ -0,0 +1,38 @@
+# Rodada 06 · Imagens reais, não stock
+
+**Garante:** nenhuma imagem fingindo ser gente da casa, com o lugar preparado para a foto real.
+**Rode quando:** o site tiver seção de equipe, escritório ou depoimento com foto.
+
+Você é o diretor de arte deste site, com acesso ao repositório. Sua única tarefa nesta rodada: tirar do ar toda imagem que finge ser gente da casa, e preparar o lugar da foto real.
+
+NÃO gere imagem de pessoa. NÃO substitua uma foto de banco de imagens por outra foto de banco de imagens. NÃO invente nome, cargo ou biografia.
+
+1. INVENTÁRIO
+   Percorra todas as imagens do projeto (pasta de assets, componentes, CMS, URLs externas) e classifique cada uma:
+   - REAL: é do negócio, do time, do produto ou do trabalho entregue;
+   - GENÉRICA: banco de imagens, ilustração de template, foto de modelo, escritório que não é o escritório;
+   - INDEFINIDA: não dá para saber sem perguntar.
+   Sinais de genérica: nome de arquivo com id numérico de banco de imagens, aperto de mão corporativo, operador de headset, sala de reunião com pessoas rindo de gráfico, foto perfeita em contexto de negócio pequeno.
+
+2. DECIDA POR IMAGEM
+   - Genérica em seção de equipe, escritório ou depoimento: remove.
+   - Genérica como fundo abstrato ou textura: pode ficar, se não afirmar nada sobre o negócio. Diga isso na tabela.
+   - Indefinida: pergunte antes de mexer.
+
+3. PREPARE O LUGAR DA FOTO REAL
+   - Componente de equipe com foto, nome e cargo (nunca só cargo).
+   - Proporção fixa com object-fit: cover, para foto de celular vertical não quebrar a grade quando chegar.
+   - Tamanho responsivo, carregamento preguiçoso fora da primeira tela e dimensões declaradas, para não pular layout.
+   - Texto alternativo descrevendo quem está na foto, não "foto da equipe".
+   - Enquanto a foto real não chegar: bloco fora da página com TODO. Um monograma com as iniciais é aceitável como provisório. Stock, não.
+
+4. ENTREGUE O BRIEFING DE FOTO
+   Cinco linhas, no tom de mensagem de WhatsApp, dizendo o que fotografar (equipe no local de trabalho, luz natural, sem pose corporativa), quantas fotos, orientação, resolução mínima e o que evitar.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Imagem | Onde aparece | Classificação | Ação | Substituta necessária |
+
+Em seguida, PENDÊNCIAS com as fotos que precisam ser tiradas, e o briefing de foto em bloco de citação.
+
+REGRA DE CORTE: seção de equipe vazia é melhor que seção de equipe falsa. Se a remoção esvaziar uma página inteira, diga isso e proponha o que colocar no lugar com material que já exista.

package/src/skills-lib/site-launch-kit/references/07-endereco-como-chegar.md

@@ -0,0 +1,37 @@
+# Rodada 07 · Endereço e como chegar
+
+**Garante:** qualquer pessoa descobre onde é e como chegar em menos de dez segundos.
+**Rode quando:** o negócio tiver endereço físico visível ao público.
+
+Você é um desenvolvedor front-end trabalhando no site de um negócio com endereço físico. Sua única tarefa nesta rodada: fazer com que qualquer pessoa descubra onde é e como chegar em menos de dez segundos.
+
+PRIMEIRO, VERIFIQUE SE ESTE ITEM SE APLICA. Procure endereço no repositório (rodapé, contato, schema, CMS). Se o negócio for totalmente remoto ou não tiver endereço público, PARE, responda "ITEM NÃO SE APLICA" com uma linha de justificativa, e não invente sede nenhuma.
+
+NÃO invente endereço, CEP, horário, telefone ou ponto de referência.
+
+1. INVENTÁRIO
+   Liste todo lugar onde o endereço aparece hoje e compare caractere a caractere: rodapé, página de contato, schema, textos soltos. Endereço divergente entre o site e o Google Business atrapalha a busca local além de confundir o cliente. Aponte cada divergência.
+
+2. BLOCO DE ENDEREÇO
+   Um componente único, alimentado por UMA fonte de dados, com:
+   - endereço completo em texto selecionável (para copiar e colar);
+   - botão "Como chegar" abrindo a rota no app de mapa do aparelho (link universal de mapa com o endereço codificado, não coordenadas escritas à mão);
+   - telefone e WhatsApp como link clicável (tel: e wa.me);
+   - horário de funcionamento;
+   - referências que só quem já foi conhece: estacionamento, andar, entrada, portaria, ponto de referência. Pergunte, não deduza.
+
+3. MAPA SEM DERRUBAR A PÁGINA
+   - Nada de iframe carregando junto com a página. Use imagem estática ou um bloco com aparência de mapa, e carregue o iframe só no clique ou quando ele entrar na tela.
+   - iframe com loading="lazy", title descritivo e dimensões declaradas.
+   - Se houver banner de cookies ou controle de consentimento, o mapa de terceiro respeita o consentimento antes de carregar.
+
+4. COERÊNCIA
+   Depois de implementar, o endereço precisa estar idêntico em todos os lugares e vir da mesma fonte. Anote para a rodada 12 (schema local) qual é essa fonte.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Onde | O que havia | O que há agora | Divergência corrigida |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · de quem obter · o que ele destrava".
+
+REGRA DE CORTE: ponto de referência inventado manda gente para o lugar errado. O que você não souber, pergunte; o que não for respondido, fica fora da página.

package/src/skills-lib/site-launch-kit/references/08-titles.md

@@ -0,0 +1,42 @@
+# Rodada 08 · Title próprio por página
+
+**Garante:** cada página com title próprio, descritivo e único.
+**Rode quando:** o site tiver mais de uma rota pública.
+
+Você é um especialista em SEO técnico com acesso ao repositório deste site. Sua única tarefa nesta rodada: garantir que cada página tenha um title próprio, descritivo e único.
+
+Antes de editar, detecte o terreno: framework e roteamento, onde os metadados são definidos (metadata do Next, react-helmet, tags no HTML, CMS) e se existe um title herdado do layout.
+
+NÃO mude conteúdo de página, H1 ou URL. Esta rodada é só de title.
+
+1. LEVANTE
+   Enumere TODA rota pública, inclusive páginas dinâmicas (produto, post, serviço) e as que só existem no build. Para cada uma, registre o title atual. Marque:
+   - vazio ou ausente;
+   - repetido em duas ou mais rotas;
+   - genérico ("Home", "Página inicial", "Untitled", nome do framework);
+   - herdado do layout sem sobrescrita;
+   - acima de 60 caracteres (será cortado no resultado de busca) ou abaixo de 20 (está desperdiçando espaço).
+
+2. ESCREVA OS NOVOS
+   Padrão: [o que a pessoa procura] + [diferencial ou lugar] + [marca].
+   - A palavra que a pessoa digita vem no começo, não no fim.
+   - Entre 50 e 60 caracteres, contando os separadores.
+   - Marca por último, só se couber; na home, a marca pode vir primeiro.
+   - Sem enfeite: "|", "-" ou "·" como separador, e só um deles.
+   - Sem repetir a mesma palavra três vezes.
+   - Negócio local: inclua a cidade quando ela fizer parte da busca.
+   Para rota dinâmica, escreva o template e mostre dois exemplos reais renderizados, com a contagem de caracteres de cada um.
+
+3. IMPLEMENTE
+   Um lugar só define o title de cada página, no mecanismo nativo do framework. Se houver título padrão de layout, ele fica apenas como rede de segurança, e toda página passa a sobrescrevê-lo. Página de obrigado, área logada e páginas de erro também recebem title próprio.
+
+4. CONFIRA
+   Rode o build e liste os titles renderizados. Nenhum repetido, nenhum vazio, nenhum acima de 60 caracteres.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Rota | Title antes | Title agora | Caracteres | Problema resolvido |
+
+Em seguida, PENDÊNCIAS com as páginas cujo título depende de decisão de posicionamento (qual palavra priorizar), uma linha por item.
+
+REGRA DE CORTE: título que promete o que a página não entrega gera clique e abandono, e isso é pior do que não ser clicado. Descreva a página que existe, não a que você gostaria que existisse.

package/src/skills-lib/site-launch-kit/references/09-open-graph.md

@@ -0,0 +1,35 @@
+# Rodada 09 · Prévia de link (Open Graph)
+
+**Garante:** o link rende prévia decente em qualquer lugar onde for colado.
+**Rode quando:** o site tiver domínio de produção definido.
+
+Você é um desenvolvedor front-end responsável pela primeira impressão deste site fora dele. Sua única tarefa nesta rodada: fazer o link render uma prévia decente em qualquer lugar onde for colado.
+
+Antes de editar, detecte: framework, onde os metadados são definidos, se existe domínio de produção configurado em algum lugar (variável de ambiente, config, sitemap) e se já há alguma imagem de marca no projeto.
+
+NÃO invente domínio. Sem domínio de produção definido, use a variável de ambiente correspondente e registre em PENDÊNCIAS.
+
+1. TAGS, EM TODA ROTA PÚBLICA
+   og:title, og:description, og:url (absoluta), og:type, og:site_name, og:locale (pt_BR), og:image, og:image:width, og:image:height, og:image:alt, twitter:card=summary_large_image, twitter:title, twitter:description, twitter:image.
+   Regras que decidem se funciona:
+   - toda URL absoluta, com protocolo e domínio. Caminho relativo é a causa número um de prévia vazia no WhatsApp;
+   - imagem em 1200x630, JPG ou PNG, abaixo de 1 MB (o WhatsApp corta acima disso; alguns clientes só carregam abaixo de 300 KB);
+   - sem WebP e sem SVG como og:image: nem toda plataforma lê;
+   - og:title pode diferir do title da página; aqui ele é chamada, não verbete.
+
+2. A IMAGEM
+   Se o framework suportar geração dinâmica de imagem de prévia, gere por rota, com o título da página, o nome da marca e o logotipo existente. Se não suportar, crie uma imagem estática por área do site (home, serviços, blog) com o logotipo e uma frase curta. Texto grande e centralizado, com margem de segurança: o WhatsApp corta as bordas em alguns formatos de conversa.
+
+3. FAVICON E ÍCONES
+   De passagem, confira favicon, apple-touch-icon e manifest. Ícone do framework padrão ainda no ar é o mesmo problema, no lugar mais visível.
+
+4. VALIDE
+   Liste as URLs de validação e o que conferir em cada uma (validador do Facebook, do LinkedIn, do X, e o teste real: colar o link em uma conversa consigo mesmo no WhatsApp). Explique como forçar a limpeza do cache de prévia depois de corrigir. As plataformas guardam a versão antiga por dias.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Rota | og:title | Imagem usada | Dimensão · peso | Absoluta? |
+
+Em seguida, PENDÊNCIAS e a lista de validadores.
+
+REGRA DE CORTE: prévia que você não testou colando o link em algum lugar não está pronta. Se não der para testar agora, diga explicitamente o que ficou por validar.

package/src/skills-lib/site-launch-kit/references/10-breadcrumbs.md

@@ -0,0 +1,35 @@
+# Rodada 10 · Trilha de navegação
+
+**Garante:** breadcrumbs nas páginas internas, com BreadcrumbList coerente.
+**Rode quando:** o site tiver hierarquia de páginas com mais de um nível.
+
+Você é um arquiteto de informação com acesso ao repositório deste site. Sua única tarefa nesta rodada: implementar a trilha de navegação nas páginas internas.
+
+PRIMEIRO, VERIFIQUE SE SE APLICA: se o site for de página única ou tiver todas as rotas no primeiro nível, responda "ITEM NÃO SE APLICA" com uma linha de justificativa e pare. Não invente hierarquia.
+
+NÃO mude URLs. NÃO reorganize o menu. A trilha reflete a hierarquia que existe; se ela estiver errada, você aponta, não conserta aqui.
+
+1. HIERARQUIA
+   Monte a árvore real do site a partir das rotas e da navegação. Aponte as divergências entre a URL e a navegação (a página que mora em /blog/post mas é alcançada pelo menu Serviços). A trilha precisa seguir UMA das duas, e a escolha tem que ser consciente.
+
+2. COMPONENTE
+   - <nav aria-label="Trilha de navegação"> com lista ordenada.
+   - O item atual não é link e leva aria-current="page".
+   - Início é sempre o primeiro item.
+   - No mobile, a trilha não pode quebrar em três linhas: encolha os níveis do meio (Início › … › Página atual) mantendo os extremos.
+   - Nome do nível igual ao que aparece na navegação, não ao slug.
+   - Sem separador dentro do texto do link: o separador é decorativo e fica em ::after, escondido de leitor de tela.
+
+3. DADOS ESTRUTURADOS
+   JSON-LD de BreadcrumbList por página, com position começando em 1, os mesmos nomes exibidos na tela e URLs absolutas. O último item pode ficar sem URL. A marcação precisa bater com o que está visível: divergir é violação de diretriz.
+
+4. ONDE ENTRA
+   Topo da página, abaixo do cabeçalho e acima do H1. Não entra na home. Página de erro e de obrigado também ficam de fora.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Rota | Trilha exibida | JSON-LD? | Divergência encontrada |
+
+Em seguida, a árvore do site em lista indentada, e PENDÊNCIAS com as divergências que precisam de decisão.
+
+REGRA DE CORTE: trilha que não corresponde à navegação real confunde mais do que ajuda. Se a hierarquia estiver ambígua, implemente o caminho mais usado, e liste a ambiguidade em vez de escondê-la.

package/src/skills-lib/site-launch-kit/references/11-alt-text.md

@@ -0,0 +1,40 @@
+# Rodada 11 · Texto alternativo correto
+
+**Garante:** cada imagem com o alt certo pela classificação.
+**Rode quando:** antes do lançamento, depois que as imagens finais do site estiverem no lugar.
+
+Você é um especialista em acessibilidade com acesso ao repositório deste site. Sua única tarefa nesta rodada: dar a cada imagem o texto alternativo correto.
+
+Antes de escrever, olhe as imagens de fato (abra os arquivos) e leia o contexto em que cada uma aparece. Alt escrito a partir do nome do arquivo é o mesmo problema com outra roupa.
+
+NÃO troque, corte ou gere imagens. NÃO escreva "imagem de" nem "foto de" no começo do alt: o leitor de tela já anuncia que é imagem.
+
+1. INVENTÁRIO E CLASSIFICAÇÃO
+   Liste toda imagem do projeto (tags img, componentes de imagem, imagem de fundo com conteúdo, SVG inline, ícones) e classifique:
+   - INFORMATIVA: acrescenta conteúdo;
+   - DECORATIVA: enfeite, textura, divisor;
+   - FUNCIONAL: dentro de link ou botão;
+   - COM TEXTO: tem palavras dentro da imagem;
+   - COMPLEXA: gráfico, tabela, infográfico.
+
+2. ESCREVA POR CLASSIFICAÇÃO
+   - INFORMATIVA: o que se vê e por que importa ali, em até 125 caracteres, sem repetir a legenda que já está no HTML.
+   - DECORATIVA: alt="" (vazio, presente). Atributo ausente faz o leitor ler o caminho do arquivo; alt vazio faz ele pular. São coisas diferentes.
+   - FUNCIONAL: descreve a AÇÃO ou o destino ("Ir para o WhatsApp"), não a figura ("logotipo do WhatsApp").
+   - COM TEXTO: transcreva o texto embutido, na íntegra.
+   - COMPLEXA: alt curto identificando o gráfico + descrição longa próxima, em texto de verdade na página.
+   Logotipo do próprio site no cabeçalho, quando é link para a home: "Página inicial · [nome da marca]".
+
+3. DE PASSAGEM, ANOTE (sem corrigir agora)
+   Imagem sem width e height declarados, imagem acima de 300 KB, formato antigo onde caberia WebP, e imagem de primeira tela com carregamento preguiçoso (que atrasa o conteúdo principal em vez de acelerar).
+
+4. CONFIRA
+   Nenhuma tag de imagem pode ficar sem atributo alt. Rode uma busca no repositório para provar isso e mostre o comando usado.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Arquivo/Componente | Onde aparece | Classificação | Alt agora |
+
+Em seguida, a seção OTIMIZAÇÃO PENDENTE com os problemas de carregamento anotados no passo 3, e PENDÊNCIAS com as imagens que você não conseguiu interpretar sem contexto do dono.
+
+REGRA DE CORTE: alt que descreve errado é pior que alt vazio, porque mente para quem não pode conferir. Sem entender a imagem, pergunte.

package/src/skills-lib/site-launch-kit/references/12-schema-local.md

@@ -0,0 +1,34 @@
+# Rodada 12 · Dados estruturados do negócio
+
+**Garante:** JSON-LD do negócio publicado, sem nenhum campo inventado.
+**Rode quando:** depois que endereço, horário e contato estiverem definitivos no site.
+
+Você é um especialista em SEO local com acesso ao repositório deste site. Sua única tarefa nesta rodada: publicar os dados estruturados do negócio.
+
+PRIMEIRO, DECIDA O TIPO. Leia o site e escolha o tipo mais específico que descreve o negócio (Restaurant, Dentist, HomeAndConstructionBusiness, ProfessionalService, Store...), caindo para LocalBusiness só quando nenhum couber. Negócio sem endereço físico mas com área de atendimento usa LocalBusiness com areaServed e sem address, ou Organization se não atender uma região definida. Diga qual escolheu e por quê.
+
+NÃO invente nenhum valor. Todo campo vem do que já está no site ou de resposta direta do dono. Campo sem fonte fica fora do JSON: objeto incompleto é aceitável, objeto inventado não.
+
+1. FONTE ÚNICA
+   Use a mesma fonte de dados do bloco de endereço (rodada 07). Se ela não existir, crie: um objeto de configuração de onde saem tanto o HTML visível quanto o JSON-LD. Duas cópias do endereço divergem em três meses, sempre.
+
+2. CAMPOS
+   name, image, url, telephone, address (com todos os subcampos, addressCountry BR), geo quando houver coordenada confiável, openingHoursSpecification, priceRange, areaServed, sameAs (perfis oficiais: Google Business, Instagram, LinkedIn), e o tipo escolhido.
+   Regras:
+   - o nome é o nome legal de fachada, igual ao do Google Business;
+   - horário no formato do schema, com feriado e horário especial se o site mencionar;
+   - aggregateRating e review SÓ se houver avaliação real no próprio site (ver rodada 04, prova social). Nota inventada aqui é violação de diretriz e motivo de penalidade. Na dúvida, deixe de fora.
+
+3. ONDE ENTRA
+   JSON-LD em script no head, na home e na página de contato. Uma entidade por página, sem repetir o mesmo negócio em três blocos. Se o site já tiver outro schema (Organization, WebSite), amarre-os por @id em vez de criar entidades soltas duplicadas.
+
+4. VALIDE
+   Confira campo a campo contra o que está visível na página. Liste as divergências entre site, schema e perfil do Google Business (se o link do perfil estiver disponível). Indique o validador de resultados ricos e o que esperar dele.
+
+Formato de saída: depois de aplicar, o JSON-LD final em bloco de código, seguido de uma tabela markdown:
+
+| Campo | Valor | Fonte | Confere com a página? |
+
+Em seguida, PENDÊNCIAS com os campos sem fonte, um por linha.
+
+REGRA DE CORTE: schema é declaração ao buscador. Campo preenchido por estimativa é uma afirmação falsa assinada pelo site. Deixe fora e liste como pendência.

package/src/skills-lib/site-launch-kit/references/13-robots-sitemap.md

@@ -0,0 +1,40 @@
+# Rodada 13 · robots.txt e sitemap
+
+**Garante:** buscadores entram, e entram só onde devem.
+**Rode quando:** antes do deploy final, com as rotas de produção já estáveis.
+
+Você é um especialista em SEO técnico com acesso ao repositório deste site. Sua única tarefa nesta rodada: garantir que os buscadores consigam entrar, e que entrem só onde devem.
+
+Antes de editar, detecte: framework, se há geração nativa de robots e sitemap, qual é o domínio de produção e se existe alguma configuração herdada de ambiente de teste.
+
+1. A CONFERÊNCIA QUE VEM PRIMEIRO
+   Procure, em TODO o projeto, qualquer bloqueio global de indexação:
+   - "Disallow: /" em robots.txt;
+   - meta robots noindex no layout, no head global ou em componente compartilhado;
+   - cabeçalho HTTP X-Robots-Tag: noindex em configuração de servidor, de host ou de middleware;
+   - variável de ambiente de "site privado" ligada em produção.
+   Este é o achado mais caro do kit inteiro: bloqueio de staging que sobe no deploy tira o site da busca inteira sem dar erro nenhum. Se encontrar, corrija e marque como CRÍTICO no relatório.
+
+2. ROBOTS.TXT
+   Gerado pelo mecanismo do framework quando houver, para não virar arquivo estático esquecido. Deve conter:
+   - permissão geral de rastreio;
+   - bloqueio apenas do que não é conteúdo (área logada, painel, rotas de API, busca interna com parâmetro, carrinho);
+   - a linha Sitemap: com a URL absoluta do sitemap.
+   Não use robots.txt para esconder página sensível: o arquivo é público e vira lista de sugestões. O que precisa ficar fora da busca leva noindex; o que precisa ficar fora do ar leva autenticação.
+
+3. SITEMAP.XML
+   Gerado a partir das rotas reais, contendo apenas URLs que devolvem 200, são canônicas e são indexáveis. Ficam de fora: página de obrigado, páginas com noindex, redirecionamentos, rotas de sistema. lastmod com data real de modificação do conteúdo. Se o site tiver muitas páginas dinâmicas, gere a partir da fonte de conteúdo.
+
+4. COERÊNCIA
+   Cruze as três listas: rotas existentes, sitemap e diretivas de indexação. Nenhuma URL pode estar no sitemap e bloqueada ao mesmo tempo. Confira também canonical e a convenção de barra final.
+
+5. DEPOIS DO DEPLOY
+   Escreva o passo a passo curto: verificar o domínio no Search Console, enviar o sitemap, e usar a inspeção de URL na home para confirmar que ela é indexável.
+
+Formato de saída: depois de aplicar, o conteúdo final de robots.txt em bloco de código, e uma tabela markdown:
+
+| Rota | No sitemap? | Indexável? | Coerente? |
+
+Em seguida, ACHADOS CRÍTICOS (se houver bloqueio herdado), PENDÊNCIAS e o passo a passo pós-deploy.
+
+REGRA DE CORTE: se você não tiver certeza de que uma rota deve ser indexada, deixe-a fora do sitemap e liste em PENDÊNCIAS. Sitemap é uma recomendação de prioridade, não um inventário de tudo que existe.

package/src/skills-lib/site-launch-kit/references/14-privacidade-termos.md

@@ -0,0 +1,39 @@
+# Rodada 14 · Privacidade e termos (LGPD)
+
+**Garante:** política e termos que descrevem o que ESTE site faz, gerados do inventário técnico.
+**Rode quando:** depois que todos os formulários, scripts e integrações estiverem definidos.
+
+Você é um desenvolvedor encarregado da conformidade básica deste site. Sua única tarefa nesta rodada: publicar a política de privacidade e os termos de uso que descrevem o que ESTE site faz.
+
+DECLARAÇÃO OBRIGATÓRIA NA ENTREGA: o texto produzido aqui é base técnica redigida a partir do código, não parecer jurídico. Escreva isso no relatório final e recomende revisão profissional antes de tratar dado sensível, dado de criança ou operação em outro país.
+
+NÃO copie política genérica. NÃO invente razão social, CNPJ, endereço, prazo de retenção ou nome de encarregado.
+
+1. INVENTÁRIO TÉCNICO (é daqui que sai o texto)
+   Percorra o repositório e levante:
+   - todo formulário: quais campos coleta, para onde envia, onde armazena, quem recebe notificação;
+   - todo script de terceiro: analytics, pixel de anúncio, mapa, chat, fonte externa, captcha, vídeo incorporado;
+   - todo cookie e armazenamento local criado, próprio ou de terceiro;
+   - integrações de backend: e-mail transacional, CRM, planilha, webhook, gateway de pagamento.
+   Essa lista é o esqueleto da política. Serviço que você não encontrar no código não entra no texto.
+
+2. A POLÍTICA DE PRIVACIDADE
+   Seções: quem é o controlador; quais dados são coletados e como; para que são usados; com quem são compartilhados (lista real do passo 1, nominal); por quanto tempo são guardados; cookies e para que servem; direitos do titular pela LGPD e como exercê-los; canal de contato; data da última atualização.
+   Linguagem direta, em português claro, sem parágrafo jurídico decorativo. Todo campo que depende do dono entra como marcador explícito ({{RAZAO_SOCIAL}}, {{CNPJ}}, {{EMAIL_ENCARREGADO}}) e vai para PENDÊNCIAS. Nunca preencha por estimativa.
+
+3. TERMOS DE USO
+   Versão curta e honesta: o que o site oferece, o que não garante, regras de uso, propriedade do conteúdo, limitação de responsabilidade, foro. Mesma regra de marcadores.
+
+4. AS LIGAÇÕES
+   - Links no rodapé de TODAS as páginas.
+   - Link ao lado de cada botão de envio de formulário, junto do aviso de consentimento.
+   - Se houver banner de cookies, ele precisa apontar para a política e a URL precisa existir. Se o banner apontar para lugar nenhum, conserte aqui e diga que estava quebrado.
+   - Se houver pixel ou analytics carregando ANTES do consentimento, aponte isso como achado: é o descompasso mais comum entre o que o banner promete e o que o código faz.
+
+Formato de saída: depois de aplicar, o inventário do passo 1 em tabela markdown:
+
+| Dado/Serviço | Onde é coletado | Para onde vai | Consta na política? |
+
+Em seguida, PENDÊNCIAS com todos os marcadores a preencher, a lista de achados de consentimento, e a declaração de que o texto é base técnica e não parecer jurídico.
+
+REGRA DE CORTE: política que descreve coleta que o site não faz é tão ruim quanto política que omite a que ele faz. O texto descreve o inventário, nada além dele.

package/src/skills-lib/site-launch-kit/references/15-medicao.md

@@ -0,0 +1,35 @@
+# Rodada 15 · Medição de lançamento
+
+**Garante:** cada ação que vale dinheiro registrada com nome que faz sentido daqui a três meses.
+**Rode quando:** na véspera ou no dia do lançamento, com os pontos de contato finais no site.
+
+Você é responsável pela medição deste site. Sua única tarefa nesta rodada: garantir que, no dia do lançamento, cada ação que vale dinheiro seja registrada com um nome que faça sentido daqui a três meses.
+
+Antes de editar, detecte: framework, se já existe alguma ferramenta de medição instalada (analytics, pixel, tag manager), se há banner de consentimento e quais são os pontos de contato do site.
+
+NÃO instale quatro ferramentas. NÃO envie dado pessoal como parâmetro de evento (nome, e-mail, telefone, CPF). NÃO invente conta nem identificador de medição: sem o identificador, deixe a variável de ambiente declarada e registre em PENDÊNCIAS.
+
+1. LEVANTAMENTO
+   Liste o que já está instalado e o que cada coisa mede hoje. Duplicação é comum: analytics carregado duas vezes conta cada visita em dobro. Liste também todo ponto de contato: formulários, WhatsApp, telefone, e-mail, download, agendamento, CTA principal e o da barra fixa.
+
+2. NOMENCLATURA (faça isto antes de escrever código)
+   Defina o padrão e escreva-o em um arquivo de documentação do projeto: objeto_ação em minúsculas com sublinhado (formulario_enviado, whatsapp_clique, telefone_clique, orcamento_iniciado). Parâmetros úteis: origem do clique (herói, barra fixa, rodapé), página e identificador do formulário. Nada de dado pessoal. Uma constante por evento, em um arquivo só: nome de evento digitado à mão em cada componente diverge em uma semana.
+
+3. IMPLEMENTAÇÃO
+   - Script carregado sem travar a renderização.
+   - Nada dispara antes do consentimento, se houver banner.
+   - Anonimização de IP quando a ferramenta permitir.
+   - Um disparo por ação, protegido contra clique duplo e contra recarregamento da página de obrigado.
+   - Página de obrigado como conversão principal, ligada à rodada 03 (tempo de resposta).
+   - Se houver pixel de anúncio, dispare o mesmo evento nele, com o mesmo nome, para os relatórios baterem.
+
+4. TESTE DE FUMAÇA
+   Em ambiente local ou de teste, execute cada ação e confirme o evento no depurador da ferramenta. Um evento não testado é um evento que não existe. Liste o que você conseguiu confirmar e o que ficou pendente.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Evento | Gatilho (arquivo · elemento) | Parâmetros | Testado? |
+
+Em seguida, PENDÊNCIAS (identificadores de conta, acessos, eventos não testados) e o padrão de nomenclatura em bloco de código, pronto para entrar na documentação do projeto.
+
+REGRA DE CORTE: meça poucas coisas e meça direito. Vinte eventos mal nomeados produzem um painel que ninguém abre; quatro eventos certos respondem à única pergunta que importa, que é de onde veio o cliente.

package/src/skills-lib/wizz-router/SKILL.md

@@ -49,7 +49,7 @@ Avalie a **Área**: quantas áreas o pedido toca (design, dev, copy, seo, growth
 - *1 área, mas 2+ fatores → maestro:* `m06` ("refactor de infra: banco de dados, APIs, deploy, monitoria"): 1 área (dev), porém multi-passo + precisa planejar + arquitetura de alto risco → `wizz-maestro` mesmo sem cruzar área.
 - *2+ áreas, cada parte leve → ainda maestro (cláusula 1):* ex. "ajusta a cor do botão secundário E troca uma palavra na CTA": cada mudança isolada é trivial, mas cruza 2 áreas (designer + copy) no mesmo pedido, então cai na cláusula 1 e vai pro maestro mesmo sem multi-passo pesado. O dataset atual não tem um caso equivalente (`m01`-`m12` sempre combinam 2+ áreas com complexidade alta); é a lacuna de calibração apontada pelo finding M1.
 
-Ao delegar (pro maestro ou pro agente de área), declare o brief no formato do [protocolo de handoff compartilhado](../../core-skills/_shared/handoff-protocol.md): `origem: wizz-router` (anti-loop — quem recebe nunca te devolve o mesmo pedido), resumo do cerebro se já tiver sido consultado, decisões já tomadas e a seção relevante da skill.
+Ao delegar (pro maestro ou pro agente de área), declare o brief no formato do [protocolo de handoff compartilhado](../../core-skills/_shared/handoff-protocol.md): `origem: wizz-router` (anti-loop — quem recebe nunca te devolve o mesmo pedido), resumo do cerebro se já tiver sido consultado, decisões já tomadas e a seção relevante da skill. Inclua também o **veredito dos 4 fatores** — em especial `precisa planejar: sim/não` — para quem recebe aplicar o Gate de Planejamento (módulo wizz, `_shared/planning-gate.md`) sem re-derivar: com fator planejamento SIM e sem PRD/story/brief correspondente, quem recebe pergunta 1x se cria o artefato antes de executar; resolvido o gate, a cadeia segue automática.
 
 ### B) Fora de projeto Wizz (modo flat) — aí você roteia direto
 

package/src/skills-lib/wizz-router/references/routing-table-flat.md

@@ -59,6 +59,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Paid ads, anúncios, Google Ads, Meta Ads, TikTok Ads, mídia paga | `paid-ads` + `ad-creative` + `analytics-tracking` + **MCP meta-ads** | 1 |
 | Gestão de campanha Meta/Facebook/Instagram via API real | **MCP meta-ads** (`mcp-meta-ads`) direto | 1 |
 | Lançamento de feature, lançamento de produto, go-to-market | `launch-strategy` + `social-content` + `email-sequence` | 1 |
+| Site pronto pra subir, pré-lançamento de SITE, "revisa antes do deploy", checklist de go-live, ou item pontual pré-lançamento (og:image/prévia de link, FAQ com schema, robots.txt, LGPD, alt text) | `site-launch-kit` | 1 |
 | Preço, planos, pricing, monetização | `pricing-strategy` + `paywall-upgrade-cro` | 1 |
 | Churn, retenção, cancelamento, NPS | `churn-prevention` + `revops` | 1 |
 | Conversão de página, CRO, otimização de funil | `page-cro` + `copywriting` + `form-cro` | 1 |