wizz-method 1.17.0 → 1.18.1

package/src/skills-lib/tracking-audit/references/modo-implantacao.md

@@ -0,0 +1,89 @@
+# Modo implantação
+
+Checklist executável para antes de subir campanha. Roda de cima para baixo. Cada item tem um jeito de verificar, não é declaração de fé.
+
+Régua: leia o Passo 0 do `SKILL.md` antes. Sem régua declarada, o relatório sai sem número.
+
+## 1. Página e carregamento
+
+| Verificar | Como | Reprova quando |
+|---|---|---|
+| Página abre no mobile real | `agent-browser` em viewport de celular | Layout quebra ou bloco some |
+| Tempo até o conteúdo principal | PageSpeed Insights, aba mobile | Fora da meta declarada pela régua do projeto |
+| Redirect | Abrir o link do anúncio sem encurtador no meio | Qualquer salto extra ou loop |
+| SSL | Cadeado e certificado válido no domínio final | Aviso do navegador |
+
+Furou aqui: é trabalho de dev. Não mexa em criativo antes de resolver.
+
+## 2. Pixel e servidor
+
+| Verificar | Como | Reprova quando |
+|---|---|---|
+| Pixel presente na página | Extensão de debug da plataforma ou console | Não dispara `PageView` |
+| Posição do disparo | Ver se o `PageView` sobe antes do conteúdo visível | Dispara em `onload` tardio: infla connect rate e mente sobre a visita |
+| Evento de conversão do lado do servidor (CAPI) | Painel de qualidade da plataforma | Só navegador, sem servidor |
+| Deduplicação | `event_id` igual entre navegador e servidor | Sem `event_id`: a mesma venda conta duas vezes |
+| Domínio verificado | Painel de negócio da plataforma | Não verificado: perde atribuição em iOS |
+
+> O pixel mede o pixel. Um connect rate bonito com página lenta é métrica maquiada, não conversão.
+
+## 3. Eventos priorizados
+
+Instale nesta ordem. Os quatro primeiros são obrigatórios; os outros entram quando o funil tiver a etapa.
+
+1. `PageView` — visita à página de vendas
+2. `ViewContent` — chegou ao bloco de oferta (não é o mesmo que abrir a página)
+3. `InitiateCheckout` — clicou para comprar
+4. `Purchase` — venda aprovada, com valor e moeda
+5. `AddPaymentInfo` — preencheu pagamento, separa atrito de checkout de desistência de preço
+6. `Lead` — captura, quando existir etapa de lead
+7. `Subscribe` ou evento de recorrência, quando existir
+8. Evento próprio de upsell ou order bump, quando existir
+
+Regra: evento sem valor monetário em `Purchase` inutiliza ROAS. Evento duplicado inutiliza tudo.
+
+## 4. Tags e atribuição
+
+Ver `utm-e-atribuicao.md` para os templates. O que a implantação precisa provar:
+
+- O template de UTM está colado no campo de parâmetros de URL do anúncio, não no destino do anúncio.
+- Cada parâmetro carrega nome **e** ID.
+- O parâmetro nativo da plataforma de checkout (quando existir) recebe a mesma informação empacotada, porque o checkout nem sempre repassa `utm_*`.
+- Nenhum nome de campanha, conjunto ou anúncio contém `|`, `#`, `&` ou `?`.
+- O padrão de nomenclatura está escrito em algum lugar que a próxima pessoa lê.
+
+## 5. Repasse pelo checkout
+
+Este é o item que mais falha e o mais fácil de esquecer.
+
+1. Abra a página com uma UTM de teste na URL.
+2. Clique para comprar.
+3. Na página de checkout, confirme que os parâmetros chegaram (URL, campo escondido ou painel da plataforma).
+4. Confirme que o webhook de venda entrega esses parâmetros para o destino final (banco, planilha, painel de atribuição).
+
+Quebrou entre 2 e 3: o checkout não repassa. Use o parâmetro nativo.
+Quebrou entre 3 e 4: o problema é a integração, não a tag.
+
+## 6. Compra-teste por caminho
+
+Cada rota de entrada recebe uma compra real de teste antes de investir:
+
+- anúncio
+- link da bio
+- story
+- destaque
+- direct ou conversa
+
+Para cada rota, registre: a venda apareceu no banco, apareceu no painel de atribuição, e apareceu com a origem certa. Rota que não passa nas três é rota cega.
+
+## 7. Fechamento
+
+Antes de liberar a subida, o relatório precisa responder sim para as cinco:
+
+1. A visita é medida no instante certo?
+2. A venda chega ao banco próprio?
+3. A venda sabe de qual anúncio veio, por ID?
+4. O orgânico é o que sobra depois de tudo taguear, e não um balde de preguiça?
+5. Existe pelo menos uma compra-teste aprovada por rota?
+
+Qualquer "não" vira achado `CRÍTICO` ou `ALTO`. Nada sobe com um `CRÍTICO` aberto.

package/src/skills-lib/tracking-audit/references/utm-e-atribuicao.md

@@ -0,0 +1,75 @@
+# UTM e atribuição
+
+O cimento de todo o resto. Se a tag está errada, o funil inteiro mede ficção.
+
+## A regra central
+
+Cada parâmetro carrega **nome e ID**, separados por um delimitador fixo. O nome existe para humano ler; o ID existe para a atribuição sobreviver a renomeação.
+
+```
+utm_campaign={{campaign.name}}|{{campaign.id}}
+utm_medium={{adset.name}}|{{adset.id}}
+utm_content={{ad.name}}|{{ad.id}}
+utm_term={{placement}}
+utm_source=<plataforma>
+```
+
+Cole no campo **parâmetros de URL** do anúncio, nunca no destino.
+
+## Redundância no parâmetro nativo
+
+Muito checkout não repassa `utm_*` para o webhook de venda. Quando a plataforma de checkout tem parâmetro próprio (por exemplo `xcod`, `src` ou `sck`), empacote a mesma informação lá também, com um separador longo e improvável:
+
+```
+xcod=<origem><SEP><campaign.name>|<campaign.id><SEP><adset.name>|<adset.id><SEP><ad.name>|<ad.id><SEP><placement>
+```
+
+O separador precisa ser uma string que nunca apareça em nome de campanha. Escolha uma vez e nunca mude: mudar quebra o histórico.
+
+## Delimitadores proibidos em nomes
+
+Nunca use `|`, `#`, `&` ou `?` em nome de campanha, conjunto ou anúncio. São delimitadores da própria string de tag.
+
+Violou: **recriar a campanha**. Renomear não resolve, porque a plataforma continua servindo o nome antigo em cache para as impressões já entregues.
+
+Padrão de nome que não dá problema: minúscula, sem acento, palavras separadas por hífen ou underscore, campos em ordem fixa. Escreva o padrão em algum lugar. Padrão que só existe na cabeça de alguém não é padrão.
+
+## Outras plataformas
+
+O formato é o mesmo em toda plataforma de mídia: macro nativa da plataforma preenchendo `utm_*`, mais o empacotamento no parâmetro nativo do checkout quando ele existir.
+
+| Plataforma | O que muda |
+|---|---|
+| Meta | Macros `{{campaign.name}}`, `{{campaign.id}}`, `{{adset.*}}`, `{{ad.*}}`, `{{placement}}` |
+| Google | Macros entre chaves simples, mais `{lpurl}?` na frente e `keyword`, `device`, `network` |
+| TikTok, Kwai, Taboola | Mesma estrutura, nomes de macro próprios da plataforma |
+
+Antes de escrever o template de uma plataforma, confirme o nome exato da macro na documentação dela. Macro errada entrega a string literal `{{campaign.id}}` na URL, e ninguém percebe até a primeira venda.
+
+Existe variação a mais quando há cloaker na frente do checkout: um conector extra para não quebrar a string. Confirme com quem instalou o cloaker.
+
+## O balde do orgânico
+
+"Orgânico" não é canal. É tudo que chegou sem tag: destaque do Instagram sem UTM, link na bio sem UTM, direct, recompra, boca a boca.
+
+Diagnóstico: tague **todas** as rotas próprias (bio, destaque, story, direct, e-mail, grupo) e observe o orgânico cair. O que sobrar depois disso é orgânico de verdade. O tamanho da queda é a prova de quanto o balde estava mentindo.
+
+Padrão sugerido para rota própria:
+
+```
+utm_source=instagram&utm_medium=<bio|destaque|story|direct>&utm_campaign=<nome-do-destaque-ou-post>
+```
+
+## Primeiro toque
+
+Último clique é o padrão de quase toda ferramenta, e ele esconde qual anúncio **apresentou** a oferta. Guarde o primeiro toque no seu banco (primeira UTM vista pelo visitante, com data) e compare com o último. Multi-toque simples, dois campos, resolve a maior parte das decisões de criativo.
+
+## Conferência rápida
+
+Cinco checagens que pegam quase todo erro de tag:
+
+1. Abra o anúncio em preview e leia a URL final: tem macro literal sobrando?
+2. A UTM sobrevive ao redirect até o checkout?
+3. O webhook de venda entrega os campos ao banco?
+4. Dois anúncios diferentes geram `utm_content` diferentes?
+5. Renomear um anúncio quebra a atribuição? Se quebrar, está atribuindo por nome.

package/src/skills-lib/ui-component-curator/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ui-component-curator
-description: analyze an existing frontend project, infer its visual style and product tone, then research and recommend compatible UI components and effects from 21st.dev and superdesign. use when the user wants help choosing components, effects, sections, or visual patterns that fit an existing project — especially hero effects, cards, buttons, testimonials, pricing sections, navigation, or any interactive pattern. trigger whenever the user wants to add a UI element and wants Claude to study the project first before suggesting options. always read the codebase before recommending, send links for confirmation, and plan before editing.
+description: analyze an existing frontend project, infer its visual style and product tone, then research and recommend compatible UI components and effects from public component catalogs, registries and source repositories. use when the user wants help choosing components, effects, sections, or visual patterns that fit an existing project — especially hero effects, cards, buttons, testimonials, pricing sections, navigation, or any interactive pattern. trigger whenever the user wants to add a UI element and wants Claude to study the project first before suggesting options. always inspect the codebase and exact component sources, provide evidence and plan before editing.
 ---
 
 # Overview
@@ -9,7 +9,7 @@ Read the project. Infer its design language. Then find components that feel like
 
 Act as a UI curator with taste and restraint — not a gallery explorer. Optimize for consistency over novelty.
 
-**Golden rule:** Do not edit before confirming. Plan first → send links → wait for approval → then edit.
+**Golden rule:** Inspect the project → search real sources → document evidence → plan → implement within the user's authorization. Ask only when a material choice or paid access is unresolved.
 
 ---
 
@@ -30,7 +30,13 @@ Extract the project's design DNA:
 
 Do not ask the user to describe the style unless the project has no inspectable UI at all.
 
-## 2. Search 21st.dev and superdesign
+## 2. Search and inspect public sources
+
+Start with existing project components. Then search appropriate public sources: [React Bits](https://reactbits.dev/), [Cult UI](https://www.cult-ui.com/docs), [Componentry](https://componentry.dev/), or [shadcn/ui](https://ui.shadcn.com/docs). Compare at least two suitable sources when available.
+
+Open the exact demo and source file/registry item. Check the actual imports, license, dependencies, stack variant and revision; use current official documentation (Context7 when available) for API compatibility. Inspect animation/interaction in the available browser; label static-only inspection honestly. If a source fails, record the failure and continue elsewhere.
+
+Record search terms, exact URLs/paths, revision/date, license, dependencies, visual inspection status and acceptance/rejection reason in the project's design artifact (or `design-research.md`). A catalog homepage or search snippet is not component evidence. Never invent filenames, components or test results.
 
 Use the inferred style DNA as the search filter. Prefer:
 - options that feel native to the current project
@@ -50,9 +56,9 @@ For each candidate, say briefly:
 
 Provide a compact plan: what changes, which files, any dependency or styling adaptation needed.
 
-## 5. Send links and wait for confirmation
+## 5. Present evidence and proceed within scope
 
-Do not proceed to edit until the user confirms.
+Send the exact candidate links and recommendation. If the user authorized implementation and the design direction is known, proceed with the best fit. Ask only for unresolved direction, paid access or a scope change.
 
 ---
 
@@ -98,5 +104,5 @@ Up to 2 backup options only if genuinely different and useful.
 ## Implementation plan
 What changes, which files, any dependency or adaptation work.
 
-## Links for confirmation
-The candidate links. Await user approval before editing.
+## Research evidence
+Exact candidate demo/source links, revision/date, license and dependencies, visual inspection status, decisions and unavailable sources. State what still needs a user decision.

package/src/skills-lib/ui-ux-pro-max/SKILL.md

@@ -17,13 +17,28 @@ Reference these guidelines when:
 
 ## First Step
 
-Analyze the user request (product type, style keywords, industry, stack), then **always start with `--design-system`** to get a comprehensive recommendation with reasoning:
+### Wizz: construction entry point
+
+Before producing UI code, inspect the existing project and choose the research skill:
+
+- New landing page or a full page composition: invoke `skill:premium-landing-ui-researcher` for source research and section planning.
+- A component or effect in an existing project: invoke `skill:ui-component-curator` to inspect compatible candidates.
+- Existing UI polish only: invoke `skill:impeccable`; invoke `skill:taste-skill` when a redesign direction is needed.
+- HTML prototype/visual variants: invoke `skill:huashu-design`. Stitch-to-React conversion: invoke `skill:react-components`.
+
+The local Python database below recommends design tokens and patterns; it does **not** search the web, inspect component source code, or prove that a component exists. For component research, require exact demo/source URLs, inspected files or registry items, revision/date, license, dependencies and a fit decision. Continue with an available public source if one fails; state any unverified result. Do not claim research based only on the database output.
+
+### Local design-system search
+
+Analyze the user request (product type, style keywords, industry, stack). Use `--design-system` for a new page/project or a change to the overall visual direction:
 
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "<product_type> <industry> <keywords>" --design-system [-p "Project Name"]
+python3 scripts/search.py "<product_type> <industry> <keywords>" --design-system [-p "Project Name"]
 ```
 
-If user doesn't specify a stack, default to `html-tailwind`. Needs Python 3 — see `references/workflow-guide.md` if `python3 --version` fails.
+Run from this skill's directory. For a targeted concern, use `--domain`; for implementation guidance, use a separate `--stack` query inferred from the project. This bundled engine ignores `--stack` in `--design-system` mode. If no stack can be inferred and it matters, ask instead of assuming Tailwind.
+
+Use one dominant intent and 2–5 meaningful terms per query. Verify the returned category and fit before applying results. Retry once with a narrower query if results are off-topic; after that, label general guidance as a fallback. Do not persist unverified output. When using `--persist`, pass `--output-dir` for the project and inspect existing design artifacts first: this bundled version can overwrite them. Needs Python 3 — see `references/workflow-guide.md` if `python3 --version` fails.
 
 ## References (load on demand)
 

package/src/skills-lib/ui-ux-pro-max/references/search-reference.md

@@ -21,7 +21,7 @@ Load this file when picking a `--domain` or `--stack` value, or when choosing an
 
 | Stack | Focus |
 |-------|-------|
-| `html-tailwind` | Tailwind utilities, responsive, a11y (DEFAULT) |
+| `html-tailwind` | Tailwind utilities, responsive, a11y (only when project uses it) |
 | `react` | State, hooks, performance, patterns |
 | `nextjs` | SSR, routing, images, API routes |
 | `vue` | Composition API, Pinia, Vue Router |
@@ -38,8 +38,8 @@ The `--design-system` flag supports two output formats:
 
 ```bash
 # ASCII box (default) - best for terminal display
-python3 skills/ui-ux-pro-max/scripts/search.py "fintech crypto" --design-system
+python3 scripts/search.py "fintech crypto" --design-system
 
 # Markdown - best for documentation
-python3 skills/ui-ux-pro-max/scripts/search.py "fintech crypto" --design-system -f markdown
+python3 scripts/search.py "fintech crypto" --design-system -f markdown
 ```

package/src/skills-lib/ui-ux-pro-max/references/workflow-guide.md

@@ -37,14 +37,14 @@ Extract key information from user request:
 - **Product type**: SaaS, e-commerce, portfolio, dashboard, landing page, etc.
 - **Style keywords**: minimal, playful, professional, elegant, dark mode, etc.
 - **Industry**: healthcare, fintech, gaming, education, etc.
-- **Stack**: React, Vue, Next.js, or default to `html-tailwind`
+- **Stack**: infer from project dependencies. If unknown and needed, ask.
 
-### Step 2: Generate Design System (REQUIRED)
+### Step 2: Choose the search mode
 
-**Always start with `--design-system`** to get comprehensive recommendations with reasoning:
+Use `--design-system` for new pages/projects or overall visual direction. Use a focused `--domain` for a targeted concern and a separate `--stack` query for implementation. The bundled engine ignores `--stack` in design-system mode. Verify relevance, retry once with a narrower query, and label an unmatched result as a fallback.
 
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "<product_type> <industry> <keywords>" --design-system [-p "Project Name"]
+python3 scripts/search.py "<product_type> <industry> <keywords>" --design-system [-p "Project Name"]
 ```
 
 This command:
@@ -55,40 +55,40 @@ This command:
 
 **Example:**
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "beauty spa wellness service" --design-system -p "Serenity Spa"
+python3 scripts/search.py "beauty spa wellness service" --design-system -p "Serenity Spa"
 ```
 
 ### Step 2b: Persist Design System (Master + Overrides Pattern)
 
-To save the design system for hierarchical retrieval across sessions, add `--persist`:
+Run from this skill's directory. To persist into the user's project, add `--persist --output-dir <project-root>`. Read any existing design artifacts first: this bundled version can overwrite files, so preserve existing decisions and only persist verified output.
 
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "<query>" --design-system --persist -p "Project Name"
+python3 scripts/search.py "<query>" --design-system --persist --output-dir "<project-root>" -p "Project Name"
 ```
 
 This creates:
-- `design-system/MASTER.md` — Global Source of Truth with all design rules
-- `design-system/pages/` — Folder for page-specific overrides
+- `design-system/<project-slug>/MASTER.md` — Global Source of Truth with all design rules
+- `design-system/<project-slug>/pages/` — Folder for page-specific overrides
 
 **With page-specific override:**
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "<query>" --design-system --persist -p "Project Name" --page "dashboard"
+python3 scripts/search.py "<query>" --design-system --persist --output-dir "<project-root>" -p "Project Name" --page "dashboard"
 ```
 
 This also creates:
-- `design-system/pages/dashboard.md` — Page-specific deviations from Master
+- `design-system/<project-slug>/pages/dashboard.md` — Page-specific deviations from Master
 
 **How hierarchical retrieval works:**
-1. When building a specific page (e.g., "Checkout"), first check `design-system/pages/checkout.md`
+1. When building a specific page (e.g., "Checkout"), first check `design-system/<project-slug>/pages/checkout.md`
 2. If the page file exists, its rules **override** the Master file
-3. If not, use `design-system/MASTER.md` exclusively
+3. If not, use `design-system/<project-slug>/MASTER.md` exclusively
 
 ### Step 3: Supplement with Detailed Searches (as needed)
 
 After getting the design system, use domain searches to get additional details:
 
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "<keyword>" --domain <domain> [-n <max_results>]
+python3 scripts/search.py "<keyword>" --domain <domain> [-n <max_results>]
 ```
 
 **When to use detailed searches:**
@@ -103,10 +103,10 @@ python3 skills/ui-ux-pro-max/scripts/search.py "<keyword>" --domain <domain> [-n
 
 ### Step 4: Stack Guidelines (Default: html-tailwind)
 
-Get implementation-specific best practices. If user doesn't specify a stack, **default to `html-tailwind`**.
+Get implementation-specific best practices for the stack detected in the project. Ask if the stack matters and cannot be inferred.
 
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "<keyword>" --stack html-tailwind
+python3 scripts/search.py "<keyword>" --stack html-tailwind
 ```
 
 Available stacks: `html-tailwind`, `react`, `nextjs`, `vue`, `svelte`, `swiftui`, `react-native`, `flutter`, `shadcn`, `jetpack-compose`
@@ -124,7 +124,7 @@ Available stacks: `html-tailwind`, `react`, `nextjs`, `vue`, `svelte`, `swiftui`
 ### Step 2: Generate Design System (REQUIRED)
 
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "beauty spa wellness service elegant" --design-system -p "Serenity Spa"
+python3 scripts/search.py "beauty spa wellness service elegant" --design-system -p "Serenity Spa"
 ```
 
 **Output:** Complete design system with pattern, style, colors, typography, effects, and anti-patterns.
@@ -133,16 +133,16 @@ python3 skills/ui-ux-pro-max/scripts/search.py "beauty spa wellness service eleg
 
 ```bash
 # Get UX guidelines for animation and accessibility
-python3 skills/ui-ux-pro-max/scripts/search.py "animation accessibility" --domain ux
+python3 scripts/search.py "animation accessibility" --domain ux
 
 # Get alternative typography options if needed
-python3 skills/ui-ux-pro-max/scripts/search.py "elegant luxury serif" --domain typography
+python3 scripts/search.py "elegant luxury serif" --domain typography
 ```
 
 ### Step 4: Stack Guidelines
 
 ```bash
-python3 skills/ui-ux-pro-max/scripts/search.py "layout responsive form" --stack html-tailwind
+python3 scripts/search.py "layout responsive form" --stack html-tailwind
 ```
 
 **Then:** Synthesize design system + detailed searches and implement the design.

package/src/skills-lib/ui-ux-pro-max/scripts/search.py

@@ -71,9 +71,15 @@ if __name__ == "__main__":
 
     args = parser.parse_args()
 
-    # Design system takes priority
-    if args.design_system:
-        result = generate_design_system(
+    # Design system takes priority
+    if args.design_system:
+        if args.stack:
+            print(
+                "Warning: --stack is ignored in --design-system mode. "
+                "Run a separate --stack query for implementation guidance.",
+                file=sys.stderr,
+            )
+        result = generate_design_system(
             args.query, 
             args.project_name, 
             args.format,

package/src/skills-lib/wizz-offer-forge/SKILL.md

@@ -16,6 +16,7 @@ Um artefato mestre `OFFER-SPEC.md` contendo:
 4. **Ancoragem de Preço, Modelagem de Planos & Order Bumps / Upsells**.
 5. **Garantia Reversa / Inversão de Risco** (Risco Zero ou Ganho Duplo).
 6. **Ponte de Tráfego: Matriz de Hooks e Ângulos de Criativos**.
+7. **Plano de Medição** (eventos mínimos, padrão de UTM, metas por transição, hipótese e número que reprova).
 
 ## Princípios de Forja de Oferta
 
@@ -28,11 +29,21 @@ Um artefato mestre `OFFER-SPEC.md` contendo:
 
 ### Passo 0 — Coleta de Insumos & Ambição
 
-Consulte o contexto existente ou pergunte ao usuário:
+**Antes de perguntar qualquer coisa, leia o que já existe.** Oferta boa nasce do resultado da anterior, não de página em branco.
+
+Se a skill `cerebro` estiver instalada, rode `/cerebro ver` do projeto e faça um grep por tema em `_decisions/`. Procure especificamente: oferta anterior do mesmo público, preço que já foi testado, garantia que já foi usada, e decisão registrada que proíba algum caminho. Traga o que achou como insumo e diga na resposta de onde veio. Sem a skill instalada, pule este bloco e siga com as perguntas abaixo.
+
+Depois, consulte o contexto existente ou pergunte ao usuário:
 1. **Pesquisa de Público Prévia:** Existe um relatório da skill `pesquisa-de-publico-do-piva` ou notas de VoC? Se sim, importe como insumo primário. Se não, defina Avatar, Dor Latente e Nível de Consciência inicial.
 2. **Modelo de Negócio:** Low-ticket (R$ 10 a R$ 97), Front-end médio (R$ 197 a R$ 497) ou High-ticket / Mentoria (R$ 1.000 a R$ 10.000+)?
 3. **Veículo de Entrega:** Curso gravado, comunidade, templates/ferramentas, mentoria ao vivo, SaaS ou híbrido?
 
+### Passo 0.5 — Régua local tem precedência
+
+Se a skill `lowticket-metodologia` estiver instalada neste projeto, leia as entradas de **oferta, preço e garantia** do INDEX dela e use esses valores como régua acima dos padrões desta skill (faixas de preço, múltiplo de upsell, prazo de garantia). Declare na resposta qual régua está valendo. Onde a régua local contradisser esta skill, **a régua local vence**.
+
+Sem essa skill instalada, siga com os padrões desta skill. Nada muda.
+
 ### Passo 1 — Destilação do Mecanismo Único
 
 Consulte `references/mecanismo-unico.md`:
@@ -70,6 +81,20 @@ Consulte `references/ponte-trafego.md`:
   3. *Gancho da Demonstração do Mecanismo*
   4. *Gancho da História de Transformação / Case*
 
-### Passo 6 — Compilação e Entrega
+### Passo 6 — Plano de Medição
+
+Consulte `references/plano-de-medicao.md`.
+
+Uma oferta sem definição de sucesso não pode ser diagnosticada depois: quando ela não converte, ninguém sabe se o furo foi criativo, página, checkout ou a oferta em si. Este passo fecha esse buraco enquanto a promessa ainda está fresca.
+
+Derive da própria oferta, sem inventar número:
+- **Eventos mínimos** que precisam existir para medir esta promessa.
+- **Padrão de UTM** por canal de entrada.
+- **Metas por transição do funil**, calibradas para este ticket, com a fonte da régua declarada.
+- **A hipótese principal** em uma frase, e o **número que reprova a oferta**.
+
+Se a skill `tracking-audit` estiver instalada, delegue a implantação e a conferência para ela: aqui se declara o que precisa ser verdade, lá se prova que é.
+
+### Passo 7 — Compilação e Entrega
 
 Grave o artefato final em `{output_folder}/offers/OFFER-[NOME_SLUG].md` e apresente um resumo executivo com os 4 pontos de decisão para validação imediata do usuário.

package/src/skills-lib/wizz-offer-forge/references/plano-de-medicao.md

@@ -0,0 +1,74 @@
+# Plano de Medição da Oferta
+
+O sétimo bloco do `OFFER-SPEC.md`. Não é arquivo separado, é uma seção do artefato.
+
+Serve para uma coisa só: quando a oferta não converter, saber **onde** ela não converteu. Sem isso o diagnóstico vira arqueologia.
+
+Regra que atravessa tudo: **nada de número inventado**. Toda meta tem fonte declarada (régua da metodologia local, histórico do próprio projeto, ou combinado com o usuário). O que não tiver fonte fica escrito como pendência.
+
+## 1. Eventos mínimos
+
+Derive da promessa, não de uma lista pronta. A pergunta é: qual é o instante em que esta oferta foi aceita?
+
+Base para quase toda oferta de resposta direta:
+
+| Evento | Marca | Obrigatório |
+|---|---|---|
+| `PageView` | chegou à página | sim |
+| `ViewContent` | chegou ao bloco da oferta | sim |
+| `InitiateCheckout` | clicou para comprar | sim |
+| `Purchase` (com valor e moeda) | venda aprovada | sim |
+| `AddPaymentInfo` | preencheu pagamento | quando o checkout tiver a etapa |
+| evento do order bump | aceitou o bump | quando houver bump |
+| evento do upsell | aceitou o upsell | quando houver upsell |
+
+`Purchase` sem valor monetário inutiliza qualquer cálculo de retorno. Evento duplicado inutiliza todos.
+
+## 2. Padrão de UTM por canal
+
+Uma linha por rota de entrada que esta oferta vai usar. Toda rota, inclusive as próprias:
+
+```
+anúncio    utm_source=<plataforma>&utm_campaign=<nome>|<id>&utm_medium=<conjunto>|<id>&utm_content=<anúncio>|<id>
+bio        utm_source=instagram&utm_medium=bio&utm_campaign=<oferta>
+destaque   utm_source=instagram&utm_medium=destaque&utm_campaign=<nome-do-destaque>
+story      utm_source=instagram&utm_medium=story&utm_campaign=<oferta>
+e-mail     utm_source=email&utm_medium=<sequência>&utm_campaign=<oferta>
+```
+
+Rota sem UTM cai no balde do orgânico e some da análise. Se a skill `tracking-audit` estiver instalada, ela é a dona da implantação e da conferência disso.
+
+## 3. Metas por transição
+
+As cinco transições do funil, com a meta calibrada para **este** ticket e a fonte ao lado:
+
+| Transição | Meta | Fonte da meta |
+|---|---|---|
+| Cliques → visitas | | |
+| Visitas → checkout iniciado | | |
+| Checkout iniciado → venda iniciada | | |
+| Venda iniciada → aprovada (PIX) | | |
+| Venda iniciada → aprovada (cartão) | | |
+
+Preencher com régua declarada. Célula sem fonte fica vazia e vira pendência, nunca chute.
+
+## 4. Hipótese e número que reprova
+
+Duas frases, e elas são o coração do bloco:
+
+```
+Hipótese: <público> compra <promessa> a <preço> porque <mecanismo>,
+          e isso aparece como <métrica> acima de <número>.
+
+Reprova:  se depois de <volume mínimo de dados> a <métrica> ficar abaixo de <número>,
+          a oferta está errada e o próximo passo é <mudar promessa | mudar preço | mudar público>.
+```
+
+O volume mínimo importa tanto quanto o número. "Não converteu" com 40 visitas não é informação.
+
+## 5. Ponte com o tracking
+
+Este bloco **declara** o que precisa ser verdade. Ele não instala nada e não confere nada.
+
+- Com `tracking-audit` instalada: o passo seguinte é rodar o modo implantação dela usando este bloco como entrada.
+- Sem ela: entregue o bloco como checklist manual e diga que a conferência não foi feita.

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

@@ -20,10 +20,12 @@ Você é o **Diretor / porta de entrada** — não o orquestrador (esse é o `wi
 
 **Nota de escopo de instalação:** esta é a única skill do catálogo onde instalação **global** (`~/.claude/skills/wizz-router`) é o padrão operacionalmente correto, não uma exceção à regra "prefer local" (`skills-registry.yaml`, Doutrina de Instalação, regra 1) — sua razão de existir é rotear mesmo fora de um projeto Wizz. Fica sincronizada com o hook global `wizz-router-enforce.js` via `npm run sync:global`.
 
-**Economia de tokens:** o hook `rtk-rewrite.sh` já cuida do RTK automaticamente (não rode `rtk --version` a cada roteamento). Antes de ler arquivos crus, prefira `/graphify query`, `/cerebro ver`, ou `grep` específico.
+**Economia de tokens:** o hook `rtk-rewrite.sh` já cuida do RTK automaticamente (não rode `rtk --version` a cada roteamento). Antes de ler arquivos crus, prefira `/cerebro ver` ou `grep` específico.
 
 ## Triagem e delegação (o coração do Diretor)
 
+**Skill ≠ subagente nativo:** o campo `agent:` do registry identifica uma skill de persona. Invoque-a via `Skill` (ex.: `Skill(skill="wizz-growth", args="<brief>")`), nunca como `Agent(subagent_type="wizz-growth")`. Para execução isolada, use somente um tipo anunciado pelo runtime, como `wizz-exec-sonnet`, com a skill de área e o brief no prompt. Sem executor disponível, use a skill na sessão atual; sem a skill, informe a instalação faltante. Não invente tipos de agente.
+
 **Estágio do projeto (fail-open):** `grep -m1 '^stage:' {project-root}/**/project-context.md` (ex: `_wizz-output/project-context.md`, path configurável via `output_folder`). Se achar `prototype`/`mvp`, prefira solução leve e não recomende observabilidade/infra de produção; `production`, gates de qualidade valem integralmente. Sem arquivo: siga sem mencionar estágio.
 
 Descubra o contexto: **existe `{project-root}/_wizz/`?**

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

@@ -52,7 +52,7 @@ Use esta tabela pra mapear skills/CLIs/MCPs direto **fora de projeto Wizz** (sem
 | Gerar vídeo-ad/imagem por IA (Sora/Veo/Kling) + publicar Meta | CLI `arcads` (registry `ads`; git clone + Arcads API key) | 1 |
 | Analisar/entender vídeo existente (frames + transcrição) | CLI `claude-video` (registry designer; `npx skills add bradautomates/claude-video`) | 2 |
 | Narração / voz / TTS / clonagem de voz para vídeo | CLI `voicebox` (registry designer; app local com endpoint MCP) | 2 |
-| Componentes prontos via Magic (21st.dev) | Use diretamente: `mcp__magic__21st_magic_component_inspiration` / `mcp__magic__21st_magic_component_builder` | 1 |
+| Pesquisar componentes compatíveis com o projeto | `ui-component-curator` (demos, código e registries públicos com evidências) | 1 |
 
 ## Área de Marketing / Growth
 
@@ -61,6 +61,7 @@ Use esta tabela pra mapear skills/CLIs/MCPs direto **fora de projeto Wizz** (sem
 | Ideias de marketing, estratégia de marketing, posicionamento | `marketing-ideas` + `marketing-psychology` + `product-marketing-context` | 1 |
 | 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 |
+| Pixel/UTM/atribuição erradas, "a venda não bate com o gerenciador", "onde está furando o funil", tráfego orgânico inflado, conferir tracking antes de subir campanha | `tracking-audit` (+ `analytics-tracking` se for SaaS/produto) | 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 |
@@ -85,7 +86,6 @@ Use esta tabela pra mapear skills/CLIs/MCPs direto **fora de projeto Wizz** (sem
 | Intenção / palavras-chave | Skills a oferecer | Prioridade |
 |---|---|---|
 | O que foi decidido, contexto passado, aprendizados, histórico | `cerebro` (/ver ou /dia) | 1 |
-| Entender o codebase, mapear estrutura do projeto | `/graphify query` (antes de ler arquivos) | 1 |
 
 ---
 
@@ -97,6 +97,6 @@ Quando nenhuma skill/MCP instalado cobrir o pedido, **classifique o que falta**
 
 **Falta um MCP:** informe → `claude mcp list` → consulte `skills-registry.yaml` (`mcps:`/`mcp_utility:`, com `server` pronto) → proponha `claude mcp add <id> [-e VAR=$VAR] -- <command> [args]`. Secrets sempre via env/placeholder, nunca token real.
 
-MCPs comuns: context7 (docs de libs), magic/21st (UI), supabase (Postgres), meta-ads (Meta), exa (pesquisa). Browser/E2E é sempre via CLI `agent-browser`, nunca via MCP Playwright.
+MCPs comuns: context7 (docs de libs), supabase (Postgres), meta-ads (Meta), exa (pesquisa). Browser/E2E é sempre via CLI `agent-browser`, nunca via MCP Playwright.
 
 Para paid ads Meta, o MCP `mcp-meta-ads` dá acesso real à API Meta Marketing (campanhas, ad sets, ads, métricas, criativos). Combine com `paid-ads` + `ad-creative` + `analytics-tracking`. O `META_ACCESS_TOKEN` vem de env local: nunca exponha em logs ou código commitado.

package/tools/installer/commands/trace-report.js

@@ -36,7 +36,7 @@ function getRegistryFile() {
 // Lê e parseia skills-registry.yaml, devolvendo o catálogo de ids de
 // skills em ordem alfabética estável (mesma lista independente da ordem em
 // que as áreas/skills aparecem no YAML). Escopo deliberado: só as skills
-// `areas.*.skills[]` e as cross-cutting `utility[]` (graphify, find-skills,
+// `areas.*.skills[]` e as cross-cutting `utility[]` (find-skills,
 // enhance-prompt, wizz-router; também são skills de verdade em
 // src/skills-lib/). CLIs/MCPs/squads ficam de fora: `sel`/`desc` no
 // marcador de decisão podem citar agentes ou skills (ver encerramento.md),

package/tools/installer/modules/skills-lib.js

@@ -29,7 +29,7 @@ const { resolveAreaEntries } = require('./registry-resolve');
 /**
  * Resolve which skill ids to install from the registry for the chosen areas.
  * Empty / undefined / containing 'all' means every area. Utility skills
- * (graphify, find-skills, ...) are cross-cutting and always included.
+ * (find-skills, wizz-router, ...) are cross-cutting and always included.
  *
  * Wrapper fino sobre `resolveAreaEntries` (A16): a resolução por área vive em
  * `registry-resolve.js`; aqui só sobra reduzir as entradas resolvidas ao
@@ -43,6 +43,12 @@ function resolveSkillIds(registry, selectedAreas) {
   const entries = resolveAreaEntries(registry, selectedAreas, {
     listKey: 'skills',
     utilityKey: 'utility',
+    // Uma entrada com `module:` vem de src/modules/<module>/skills/, não de
+    // src/skills-lib/ — ela é instalada junto do módulo. Sem este gate o
+    // installer procuraria src/skills-lib/<id>/SKILL.md, não acharia, e
+    // reportaria a skill como "skipped" em toda instalação. Ela continua no
+    // registry porque o router/maestro precisa enxergá-la para rotear.
+    isActionable: (raw) => !raw.module,
   });
   return entries.map((entry) => entry.id);
 }