wizz-method 2.7.0 → 2.8.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "2.7.0",
+  "version": "2.8.0",
   "description": "Wizz Method: método de agência orientado por IA em PT-BR",
   "keywords": [
     "agile",
@@ -101,6 +101,7 @@
     "test:registry-lib-parity": "node test/test-registry-lib-parity.js",
     "test:registry-schema": "node test/test-registry-schema.js",
     "test:rehype-plugins": "node test/test-rehype-plugins.mjs",
+    "test:rel-protocol": "node test/test-rel-protocol-consistency.js",
     "test:resolve-command": "node test/test-resolve-command.js",
     "test:resolved-config": "node test/test-resolved-config.js",
     "test:resolver": "node test/test-resolve-customization.js",

package/skills-registry.yaml

@@ -88,57 +88,89 @@ areas:
         door: direcao
         when: "PORTA de direção: todo trabalho de decidir ANTES de construir. Brief visual inicial (6 decisões de estética + 3 lógicas) no kickoff. Puxa: wizz-taste-skill (direção anti-slop de brief novo) e wizz-motion-3d-director (decidir caminho motion/3D/vídeo)."
         rel:
-          pairs_with: [wizz-taste-skill, wizz-motion-3d-director]
+          before: [wizz-ui-ux-pro-max]
+          pairs_with: [wizz-motion-3d-director, wizz-taste-skill]
       - id: wizz-taste-skill
         door: direcao
         when: "Anti-slop em briefs NOVOS: lê o brief, define a direção e audita contra defaults de AI. Também cobre projeto EXISTENTE: audita o código atual, lista problemas, prioriza fixes (protocolo de redesign)."
+        rel:
+          pairs_with: [apple-design, wizz-decision-maker]
       - id: wizz-motion-3d-director
         door: direcao
         when: "Direção de motion/animação, 3D, WebGL, scroll cinematográfico, image-to-video. Decide o caminho ANTES de implementar."
+        rel:
+          before: [wizz-remotion-best-practices]
+          pairs_with: [wizz-decision-maker]
 
       # ── Porta 2: CONSTRUÇÃO E POLISH DE UI ──
       - id: wizz-ui-ux-pro-max
         entry: true
         door: construcao
         when: "PORTA de construção: criar/melhorar UI (design system, paleta, tipografia, componente, página). Puxa: wizz-premium-landing-ui-researcher (landing premium greenfield), wizz-ui-component-curator (1 componente em projeto existente), wizz-impeccable (gate de polish/acessibilidade), wizz-taste-skill (anti-slop em código existente, protocolo de redesign), wizz-huashu-design (protótipo HTML hi-fi/variantes/review) e wizz-react-components (Stitch→React)."
+        rel:
+          after: [wizz-decision-maker]
+          before: [wizz-impeccable]
+          pairs_with: [wizz-huashu-design, wizz-premium-landing-ui-researcher, wizz-ui-component-curator]
       - id: wizz-premium-landing-ui-researcher
         door: construcao
         when: "Projeto NOVO (greenfield): cria landing premium do zero, hero, 3D high-end. Estratégia source-first."
+        rel:
+          pairs_with: [wizz-ui-ux-pro-max]
       - id: wizz-ui-component-curator
         door: construcao
         when: "Projeto EXISTENTE: qual componente/efeito adicionar que combina com o estilo atual."
+        rel:
+          pairs_with: [wizz-ui-ux-pro-max]
       - id: wizz-impeccable
         door: construcao
         when: "Gate de polish/qualidade de frontend: hardening de UI, acessibilidade, anti-padrões. Refina o que já existe."
+        rel:
+          after: [wizz-ui-ux-pro-max]
       - id: wizz-huashu-design
         door: construcao
         when: "Direção visual + protótipo HTML hi-fi, exploração de variantes, review 5-dim, export MP4/GIF."
+        rel:
+          before: [wizz-react-components]
+          pairs_with: [wizz-ui-ux-pro-max]
       - id: wizz-react-components
         door: construcao
         when: "Converter design (Stitch MCP) em componentes React/Vite."
+        rel:
+          after: [wizz-huashu-design]
 
       # ── Porta 3: MOTION E ASSETS (executar animação e gerar mídia) ──
       - id: wizz-animate
         entry: true
         door: motion
         when: "PORTA de motion/assets: executar animação e gerar mídia. Craft de micro-interação (regras do Emil Kowalski: saída > entrada, só transform/opacity, reduced-motion). Puxa: wizz-design-motion-principles (auditar animação existente), wizz-remotion-best-practices (vídeo em React), wizz-canvas-design (PNG/PDF por código) e wizz-algorithmic-art (visual generativo)."
+        rel:
+          pairs_with: [wizz-design-motion-principles]
       - id: wizz-design-motion-principles
         door: motion
         when: "Auditor de movimento: revisa animação existente e aponta scale(0) no início, easing cru, reduced-motion faltando; pesa contenção/polimento/diversão pelo contexto."
+        rel:
+          pairs_with: [wizz-animate]
       - id: wizz-remotion-best-practices
         door: motion
         when: "MONTAR o filme: vídeo em React (Remotion) com áudio, SFX, legenda e timing com precisão de frame. No pipeline de vídeo é o Remotion que faz a montagem final; o hyperframes só desenha as telas mudas (regra: HyperFrames desenha, Remotion monta — ver _shared/video-pipeline.md do módulo wizz)."
         rel:
-          after: [hyperframes]
+          after: [buttercut, ctc-align, get-brolls, hyperframes, wizz-motion-3d-director]
       - id: wizz-canvas-design
         door: motion
         when: "Gerar PNG/PDF editável por código (carrossel, quote card, infográfico) com fonte/cor/logo sempre certos. Traz canvas-fonts."
+        rel:
+          pairs_with: [wizz-algorithmic-art, wizz-social-content]
       - id: wizz-algorithmic-art
         door: motion
         when: "Visual generativo por código (flow fields, ruído, partículas) para fundo/textura de hero, único a cada render, sem cara de banco de imagem."
+        rel:
+          pairs_with: [wizz-canvas-design]
       - id: ctc-align
         door: motion
         when: "Timing por forced alignment: timestamps palavra a palavra de narração TTS para sincronizar legenda, corte de cena e animação com a fala. Fonte única de timing no pipeline de vídeo; substitui Whisper e estimativa manual."
+        rel:
+          after: [voicebox]
+          before: [wizz-remotion-best-practices]
     clis:
       - id: hyperframes
         when: "DESENHAR telas de vídeo em HTML/CSS (HTML→MP4, agent-native, 20+ skills): cena isolada e MUDA — maqueta de WhatsApp/ChatGPT, gráfico animado, título, loop. NÃO usar para montagem com áudio/SFX/legenda sincronizada (posicionador de áudio falhou em produção, ~2,76s de drift; CSS vaza entre telas): a montagem final é do Remotion (regra: HyperFrames desenha, Remotion monta — ver _shared/video-pipeline.md do módulo wizz). Precisa ffmpeg + Node 22 + Chrome headless."
@@ -157,6 +189,8 @@ areas:
         install: 'd="$(mktemp -d)" && git clone https://github.com/heygen-com/hyperframes.git "$d" && git -C "$d" checkout 59a69a145bfbd0f10dee72246b68ee5d9bd71063 && npx skills add "$d" -g -y --copy && printf "%s\\n" 59a69a145bfbd0f10dee72246b68ee5d9bd71063 > "$HOME/.claude/skills/hyperframes/.wizz-pin" && rm -rf "$d" && rm -rf "$HOME/.claude/skills/remotion-to-hyperframes"'
       - id: claude-video
         when: "Analisar/entender vídeo EXISTENTE: baixa, extrai frames e transcreve para resumir, achar momentos ou diagnosticar footage. NÃO cria vídeo. Precisa ffmpeg + yt-dlp (+ Groq/OpenAI p/ transcrição sem legenda)."
+        rel:
+          pairs_with: [get-brolls]
         platform: [darwin, linux]
         # O check confere o SHA fixado, não só a existência da pasta: o bundle é
         # copiado (não clonado), então o pin é gravado num marcador no install.
@@ -169,7 +203,7 @@ areas:
         # última tag publicada lá é a v2.3.7; o 2.3.8 só existe como HEAD.
         metadata:
           version: "2.3.8"
-        when: "CAPTAR B-roll/insert: acha a fonte LITERAL do que a narração cita (o fato, a pessoa, o produto, a notícia, a tela) em YouTube (yt-dlp, sem API key), Instagram/TikTok (navegador/Playwright, sessão do usuário), Pexels/Pixabay/Wikimedia Commons/NASA ou arquivo local; gera prévia (poster, contact sheet numerado, GIF), monta um Storyboard HTML para REVISÃO HUMANA e entrega o corte com origem/autor/condições de uso registrados. Etapa de CAPTAÇÃO do pipeline de vídeo: enche a timeline de material real antes do corte fino e da montagem. Stock só quando o usuário pedir stock explicitamente — nunca como preenchimento de um beat sem fonte literal."
+        when: "CAPTAR B-roll/insert — em português: 'imagens de apoio', 'cenas de apoio', 'imagem de corte' para Reel, TikTok ou vídeo: acha a fonte LITERAL do que a narração cita (o fato, a pessoa, o produto, a notícia, a tela) em YouTube (yt-dlp, sem API key), Instagram/TikTok (navegador/Playwright, sessão do usuário), Pexels/Pixabay/Wikimedia Commons/NASA ou arquivo local; gera prévia (poster, contact sheet numerado, GIF), monta um Storyboard HTML para REVISÃO HUMANA e entrega o corte com origem/autor/condições de uso registrados. Etapa de CAPTAÇÃO do pipeline de vídeo: enche a timeline de material real antes do corte fino e da montagem. Stock só quando o usuário pedir stock explicitamente — nunca como preenchimento de um beat sem fonte literal."
         not_when:
           - "Analisar/resumir um vídeo que já se tem em mãos: é claude-video."
           - "Cortar/montar footage já captado: é buttercut (corte fino) ou wizz-remotion-best-practices (montagem final)."
@@ -177,6 +211,7 @@ areas:
           - "Desenhar uma tela/cena em HTML: é hyperframes."
           - "Minerar/estudar criativo ou oferta de concorrente (Biblioteca de Anúncios, 'baixa esse anúncio pra eu ver'): é wizz-lowticket-minerador na área ads. O get-brolls capta insert para a SUA edição, com procedência registrada — não é ferramenta de inteligência competitiva, e o fato de saber baixar um Reel não o torna uma."
         rel:
+          after: [wizz-social-content]
           before: [buttercut, wizz-remotion-best-practices]
           pairs_with: [claude-video]
         # macOS apenas: o upstream declara macOS/Windows (Linux não é testado lá)
@@ -203,6 +238,9 @@ areas:
         verify: 'command -v ffmpeg >/dev/null 2>&1 && ffmpeg -hide_banner -filters 2>/dev/null | grep -q " drawtext " && test -x "$HOME/.claude/skills/get-brolls/.venv/bin/python"'
       - id: buttercut
         when: "EDITAR vídeo por IA: cortes, selects, cenas, roughcut via XML/FFmpeg. Sugerir quando o pedido for editar/cortar vídeo. Clone-and-run no PROJETO (não é skill add), pesado: Ruby + Python + FFmpeg + WhisperX. AVISOS: ~GB de modelos (WhisperX), build demorado, só Apple Silicon."
+        rel:
+          after: [get-brolls]
+          before: [wizz-remotion-best-practices]
         platform: darwin-arm64
         # Clone-and-run: o próprio repo responde o SHA, então o check compara com o
         # pin. O install repara um clone existente em vez de falhar no git clone.
@@ -212,6 +250,8 @@ areas:
         verify: "command -v ffmpeg >/dev/null 2>&1 && command -v ruby >/dev/null 2>&1 && command -v python3 >/dev/null 2>&1"
       - id: voicebox
         when: "Voz/TTS/clonagem de voz local para narração/VO de vídeo (7 engines TTS + Whisper STT). App desktop que expõe endpoint MCP local em runtime. Clone-and-run no projeto."
+        rel:
+          before: [ctc-align]
         platform: [darwin, linux]
         # Clone-and-run: o próprio repo responde o SHA, então o check compara com o
         # pin. O install repara um clone existente em vez de falhar no git clone.
@@ -220,12 +260,17 @@ areas:
         install: "{ [ -d voicebox/.git ] || git clone https://github.com/jamiepine/voicebox.git voicebox; } && git -C voicebox fetch --tags origin && git -C voicebox checkout 2bcb98d1a8b6fe05e15fbc1559e3085669e4035d"
       - id: ctc-align
         when: "Timestamps palavra a palavra CONFIÁVEIS de narração TTS (texto conhecido): sincronizar legenda, corte de cena, animação e elemento gráfico com a fala. Fonte única de timing em vídeo — substitui timestamps do Whisper e estimativa manual. Skill da lib: ctc-align (instalação + helper align.py + regras de âncora monotônica e duração mínima). Roda em CPU, sem CUDA."
+        rel:
+          after: [voicebox]
+          before: [wizz-remotion-best-practices]
         platform: [darwin, linux]
         check: "test -x ./tools/ctc-align/.venv/bin/ctc-forced-aligner"
         install: 'mkdir -p tools/ctc-align && uv venv --python 3.12 tools/ctc-align/.venv && uv pip install --python tools/ctc-align/.venv/bin/python "git+https://github.com/MahmoudAshraf97/ctc-forced-aligner.git"'
         verify: "command -v ffmpeg >/dev/null 2>&1 && command -v uv >/dev/null 2>&1"
       - id: fal-video
         when: "GERAR vídeo/imagem por IA (Veo/Kling/Wan e outros modelos via API da fal.ai), estilo UGC/ad-ready. Substitui o arcads: mesmo caso de uso (vídeo gerado por IA), custo 50-95% menor por vídeo, sem clone-and-run pesado. Precisa FAL_KEY em .env. Sem CLI binária oficial: usa o client Node oficial @fal-ai/client como dependência do projeto."
+        rel:
+          pairs_with: [wizz-ad-creative]
         platform: [darwin, linux]
         check: "test -f node_modules/@fal-ai/client/package.json"
         # Pin de supply chain (2026-08-25): versão fixa (client oficial fal.ai); atualizar conscientemente.
@@ -234,7 +279,7 @@ areas:
         when: "Revisar/auditar UI NATIVA (iOS/macOS: SwiftUI, Flutter, React Native, Tauri, Electron) contra o Apple HIG e o Liquid Glass — compliance com o HIG, acessibilidade, dark mode, navegação. Cobre o gap que o wizz-taste-skill declara fora de escopo ('native mobile: use Apple HIG directly')."
         not_when: "UI web: aí é wizz-ui-ux-pro-max / wizz-impeccable."
         rel:
-          pairs_with: [wizz-taste-skill]
+          pairs_with: [wizz-desktop-security, wizz-taste-skill]
         platform: [darwin, linux]
         # Upstream sem licença declarada e reproduz texto do Apple HIG (122
         # páginas): o Wizz só instala a partir do upstream, no opt-in do
@@ -250,28 +295,48 @@ areas:
     agent: wizz-copy
     summary: "Copywriting: texto de venda, headlines, páginas, e-mails, sequências."
     skills:
-      # Módulo lowticket (src/modules/lowticket) — ver nota em ads.skills.
-      # Entram primeiro de propósito: copy de low ticket lê o shard antes de escrever.
-      - id: wizz-lowticket-guia
-        module: lowticket
-        when: "Leigo que quer vender produto barato e não sabe o que pedir: situa na jornada de 7 etapas e despacha. Ler ANTES de escrever copy de low ticket."
-      - id: wizz-lowticket-metodologia
-        module: lowticket
-        when: "Copy de low ticket BR/PT (página, VSL, roteiro de criativo, headline): ler o shard antes de escrever. 12c página, 18 copy, 04b §4.7-A VSL (9 vendas), 04c roteiro de criativo. O shard vence a skill genérica."
-        not_when:
-          - "SaaS, B2B, site de cliente, high ticket ou mentoria: os números não transferem."
+      # Módulo lowticket: as skills dele moram SÓ na área growth desde
+      # 2026-09-18 (decisão do dono: um dono por skill). A copy chega nelas
+      # pelo `rel` de wizz-copywriting — que é o caminho que o método usa pra
+      # tudo mais. Antes a mesma skill existia em copy, growth e ads, e o
+      # eval mostrava o custo: "qual prazo de garantia?" respondia copy,
+      # growth ou ads em amostras diferentes, porque as três estavam certas.
       - id: wizz-copywriting
         when: "Escrever copy de venda/página/headline do zero ou reescrever."
+        rel:
+          after: [pesquisa-de-publico-do-piva, wizz-offer-forge]
+          before: [wizz-copy-editing]
+          pairs_with:
+            [
+              wizz-ad-creative,
+              wizz-cold-email,
+              wizz-email-sequence,
+              wizz-humanizer,
+              wizz-lowticket-metodologia,
+              wizz-marketing-psychology,
+              wizz-page-cro,
+            ]
       - id: wizz-copy-editing
         when: "Editar/melhorar copy existente (framework Seven Sweeps). Review editorial geral."
+        rel:
+          after: [wizz-copywriting]
+          pairs_with: [wizz-social-content]
       - id: wizz-humanizer
         when: "Texto soa AI: remover padrões de escrita de máquina, dar naturalidade."
+        rel:
+          pairs_with: [wizz-copywriting]
       - id: wizz-email-sequence
         when: "Sequências de e-mail (onboarding, nurture, lançamento)."
+        rel:
+          pairs_with: [wizz-copywriting, wizz-launch-strategy, wizz-referral-program]
       - id: wizz-cold-email
         when: "Cold email / outbound B2B / prospecção."
+        rel:
+          pairs_with: [wizz-copywriting]
       - id: wizz-sales-enablement
         when: "Material de vendas: deck, one-pager, objeções, demo script, playbook."
+        rel:
+          pairs_with: [wizz-competitor-alternatives]
 
   seo:
     agent: wizz-seo
@@ -279,17 +344,33 @@ areas:
     skills:
       - id: wizz-seo-audit
         when: "Ponto de partida: auditar/diagnosticar SEO, queda de tráfego, ranking, core web vitals."
+        rel:
+          before: [distribb, wizz-ai-seo, wizz-programmatic-seo, wizz-schema-markup, wizz-site-architecture]
       - id: wizz-ai-seo
         when: "Otimizar pra ser citado por LLMs/AI search (AEO/GEO/LLMO, AI Overviews)."
+        rel:
+          after: [wizz-seo-audit]
+          pairs_with: [wizz-schema-markup]
       - id: wizz-schema-markup
         when: "Implementar dados estruturados / structured data."
+        rel:
+          after: [wizz-seo-audit]
+          pairs_with: [site-launch-kit, wizz-ai-seo]
       - id: wizz-programmatic-seo
         when: "Gerar páginas em escala pra atacar muitas keywords."
+        rel:
+          after: [wizz-seo-audit]
+          pairs_with: [wizz-free-tool-strategy, wizz-site-architecture]
       - id: wizz-site-architecture
         when: "Arquitetura de site / topic clusters / estrutura de URLs."
+        rel:
+          after: [wizz-seo-audit]
+          pairs_with: [wizz-programmatic-seo]
     clis:
       - id: distribb
         when: "EXECUTAR distribuição de SEO: publicar artigos + construir backlinks pela rede da Distribb, conectar Google Search Console, autopublicar notícias. Complementa (não duplica) as skills de SEO que só geram/auditam. Requer Distribb API + GSC (+ DataForSEO/Ahrefs no plano free)."
+        rel:
+          after: [wizz-seo-audit]
         platform: [darwin, linux]
         # O check confere o SHA fixado, não só a existência da pasta: o bundle é
         # copiado (não clonado), então o pin é gravado num marcador no install.
@@ -303,74 +384,143 @@ areas:
     skills:
       - id: wizz-marketing-ideas
         when: "Travou / quer inspiração ampla de marketing. Ponto de partida quando não sabe o canal."
+        rel:
+          pairs_with: [wizz-marketing-psychology, wizz-product-marketing-context]
       - id: wizz-marketing-psychology
         when: "Aplicar gatilhos/vieses/modelos mentais à persuasão."
+        rel:
+          pairs_with: [wizz-copywriting, wizz-marketing-ideas]
       - id: wizz-product-marketing-context
         when: "Posicionamento de produto e contexto de marketing do produto."
+        rel:
+          pairs_with: [wizz-marketing-ideas]
       - id: wizz-launch-strategy
         when: "Lançar produto/feature: Product Hunt, GTM, waitlist, beta."
+        rel:
+          pairs_with: [wizz-email-sequence, wizz-social-content]
       - id: wizz-pricing-strategy
         when: "Preço, planos, freemium, packaging, willingness to pay."
+        rel:
+          pairs_with: [wizz-offer-forge, wizz-paywall-upgrade-cro]
       - id: wizz-paywall-upgrade-cro
         when: "Tela de upgrade in-app / paywall."
+        rel:
+          pairs_with: [wizz-pricing-strategy]
       - id: wizz-churn-prevention
         when: "Churn, retenção, cancelamento, NPS."
+        rel:
+          pairs_with: [wizz-revops]
       - id: wizz-revops
         when: "Operações de receita: pipeline, métricas, processo de revenue."
+        rel:
+          pairs_with: [wizz-churn-prevention]
       - id: wizz-page-cro
         when: "Otimizar conversão de página (home, landing, pricing, feature)."
+        rel:
+          after: [wizz-tracking-audit]
+          pairs_with: [wizz-copywriting, wizz-form-cro, wizz-popup-cro]
       - id: wizz-form-cro
         when: "Otimizar formulários (fora de signup)."
+        rel:
+          pairs_with: [wizz-page-cro]
       - id: wizz-popup-cro
         when: "Otimizar popups/modais."
+        rel:
+          pairs_with: [wizz-page-cro]
       - id: wizz-onboarding-cro
         when: "Ativação pós-signup / onboarding de usuário."
+        rel:
+          pairs_with: [wizz-signup-flow-cro]
       - id: wizz-signup-flow-cro
         when: "Fluxo de signup/registro."
+        rel:
+          pairs_with: [wizz-onboarding-cro]
       - id: wizz-competitor-alternatives
         when: "Página de comparação vs concorrente / alternatives / battle card."
+        rel:
+          pairs_with: [scrapling, wizz-sales-enablement]
       - id: wizz-referral-program
         when: "Programa de indicação/afiliados."
+        rel:
+          pairs_with: [wizz-analytics-tracking, wizz-email-sequence]
       - id: wizz-free-tool-strategy
         when: "Ferramenta grátis pra captação de leads."
+        rel:
+          pairs_with: [wizz-programmatic-seo]
       - id: wizz-ab-test-setup
         when: "Montar A/B test / experimento de conversão."
+        rel:
+          pairs_with: [wizz-analytics-tracking]
       - id: wizz-analytics-tracking
         when: "Setar/auditar tracking e medição (GA4, GTM, eventos, UTM, atribuição)."
+        rel:
+          pairs_with: [wizz-ab-test-setup, wizz-referral-program, wizz-tracking-audit]
       - 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."
+        rel:
+          pairs_with: [wizz-launch-readiness, wizz-schema-markup]
       - id: pesquisa-de-publico-do-piva
         when: "Pesquisa profunda de público, VoC, níveis de consciência, matriz de ângulos e léxico nativo de oferta compilados em HTML (metodologia @soupiva)."
+        rel:
+          before: [wizz-copywriting, wizz-offer-forge]
       - id: wizz-offer-forge
         when: "Forjar oferta irresistível de resposta direta/infoproduto (mecanismo único, empilhamento de valor, garantia reversa, ponte de tráfego)."
-      # Módulo lowticket (src/modules/lowticket) — ver nota em ads.skills.
+        rel:
+          after: [pesquisa-de-publico-do-piva, wizz-lowticket-minerador]
+          before: [wizz-copywriting]
+          pairs_with: [wizz-pricing-strategy]
+      # Módulo lowticket (src/modules/lowticket) — ver nota em ads.skills. Desde
+      # 2026-09-18 o módulo inteiro mora aqui (um dono por skill): copy e ads
+      # chegam nele pelo `rel`. Isto é comentário de propósito — escrever "vale
+      # para as três áreas" dentro do `when:` da porta de entrada a deixou
+      # gulosa na medição seguinte (passou a engolir pedido de tarefa nomeada,
+      # que é exatamente a trava que a 2.7.0 tinha acabado de pôr nela).
       - id: wizz-lowticket-guia
         module: lowticket
-        when: "Porta de entrada low ticket para leigo: 'quero vender um produto barato', 'por onde começo', 'ninguém compra'. Situa na jornada de 7 etapas e despacha."
+        when: "Porta de entrada low ticket para quem não sabe o que pedir: 'quero vender um produto barato', 'por onde começo', 'ninguém compra', 'não estou vendendo', 'anúncio não funciona'. Situa na jornada de 7 etapas e despacha."
+        not_when:
+          - "O pedido já nomeia uma tarefa concreta com seus insumos (escrever uma copy, diagnosticar uma página, ler um print de campanha): vá direto na skill daquela etapa."
+        rel:
+          before:
+            [wizz-lowticket-funil, wizz-lowticket-metodologia, wizz-lowticket-minerador, wizz-lowticket-pagina, wizz-lowticket-trafego]
       - id: wizz-lowticket-metodologia
         module: lowticket
-        when: "Roteador da base low ticket BR/PT: gatilho → um shard. Régua de preço, garantia, copy e rastreamento que tem precedência sobre a skill genérica."
+        when: "Roteador da base low ticket BR/PT: gatilho → um shard (diagnóstico de funil, bid cap, criativo, oferta, página, Instagram, player de VSL, upsell, copy, rastreamento, mineração). Régua de preço, garantia, copy e rastreamento que tem precedência sobre a skill genérica — inclusive a copy de low ticket (página, VSL, roteiro de criativo, headline): ler o shard ANTES de escrever. Carrega guardrails junto. A precedência vale QUANDO o contexto do projeto ou o próprio pedido estabelecer que a operação é low ticket (faixa de preço, produto barato, tráfego direto). Se nenhum dos dois disser, a skill genérica vence: não presuma low ticket por a página ser de vendas, o produto ser um curso ou haver campanha rodando."
         not_when:
           - "SaaS, B2B, site de cliente, high ticket ou mentoria: os números não transferem."
+        rel:
+          after: [wizz-lowticket-guia]
+          pairs_with: [wizz-copywriting, wizz-lowticket-pagina, wizz-lowticket-trafego]
       - id: wizz-lowticket-funil
         module: lowticket
         when: "Escada pós-checkout de low ticket: upsell 1, upsell 2, downsell, oferta final, régua de preço por degrau e copy das páginas."
         not_when:
           - "Antes de existir um front-end que converte: estender funil sobre front que não vende multiplica zero."
+        rel:
+          after: [wizz-lowticket-guia, wizz-lowticket-pagina]
       - id: wizz-lowticket-minerador
         module: lowticket
         when: "Garimpo e veredito de oferta de concorrente: vocabulário de busca, veredito em 4 níveis, comparação lado a lado, diagnóstico de por que não escalou."
         not_when:
           - "A oferta já está definida: aí é wizz-offer-forge."
+        rel:
+          after: [wizz-lowticket-guia]
+          before: [wizz-offer-forge]
       - id: wizz-lowticket-pagina
         module: lowticket
         when: "Engenharia de performance da página de venda low ticket: connect rate, ordem do pixel, LCP/TTFB/CLS, peso acima da dobra, relatório antes e depois."
         not_when:
           - "Reescrever copy, preço ou estrutura de oferta: esta skill é o engenheiro, não o copywriter."
           - "Site institucional ou app."
+        rel:
+          after: [wizz-lowticket-guia]
+          before: [wizz-lowticket-funil]
+          pairs_with: [wizz-lowticket-metodologia, wizz-lowticket-trafego]
     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."
+        rel:
+          pairs_with: [wizz-competitor-alternatives]
         server:
           command: scrapling
           args: ["mcp"]
@@ -386,15 +536,26 @@ areas:
     summary: "Social e roteiros virais: Reels/Shorts, hooks, calendário de conteúdo. Persona Rafa, aplica o Blueprint de Roteiro Viral e roteia para as CLIs de vídeo quando o roteiro vira vídeo."
     skills:
       - id: wizz-social-content
-        when: "Criar/agendar conteúdo de social (LinkedIn, X, TikTok, IG...)."
+        when: "Criar/agendar conteúdo de social (LinkedIn, X, TikTok, IG...), o que inclui ESCREVER o texto: post, story, carrossel, legenda, thread. Gatilhos: 'escreve copy pra story', 'post pro LinkedIn', 'legenda do carrossel', 'thread pro X'."
+        not_when: "Editar/revisar texto de social já escrito: aí é wizz-copy-editing."
+        rel:
+          before: [get-brolls, postiz]
+          pairs_with: [wizz-canvas-design, wizz-content-strategy, wizz-copy-editing, wizz-launch-strategy]
       - id: wizz-content-strategy
         when: "Decidir O QUE produzir de conteúdo (topic clusters, calendário, pilares)."
+        rel:
+          pairs_with: [wizz-social-content]
       - id: wizz-copy-editing
         when: "Revisar/editar o texto do roteiro ou da legenda antes de publicar."
+        rel:
+          after: [wizz-copywriting]
+          pairs_with: [wizz-social-content]
     clis:
       - id: postiz
         when: "PUBLICAR/agendar de verdade em redes sociais (30+ integrações) a partir do conteúdo que o wizz-social já gerou. Separa 'gerar' (Wizz) de 'publicar' (Postiz). Precisa autenticar antes (`postiz auth:login` ou env `POSTIZ_API_KEY`); para imagem/vídeo a própria CLI faz o upload."
         not_when: "Escrever o roteiro ou a legenda: isso é skill da área (wizz-social-content, wizz-copy-editing)."
+        rel:
+          after: [wizz-social-content]
         # Item 30 da auditoria (2026-09-11, Parte 3.7). Pin de supply chain
         # (2026-09-12): versão publicada fixa no npm, atualizar conscientemente.
         # CLI, não MCP: o schema de `mcps:` deste registry só aceita stdio
@@ -411,35 +572,36 @@ areas:
     skills:
       - id: wizz-paid-ads
         when: "Estratégia de campanha, targeting, bidding, ROAS/CPA. Decidir/rodar ads."
+        rel:
+          pairs_with: [wizz-ad-creative, wizz-tracking-audit]
       - id: wizz-ad-creative
         when: "Gerar/iterar criativos e headlines de anúncio em escala (RSA, variações)."
+        rel:
+          pairs_with: [fal-video, wizz-copywriting, wizz-paid-ads]
       - id: wizz-analytics-tracking
         when: "Tracking de conversão pros anúncios (compartilhada com growth)."
+        rel:
+          pairs_with: [wizz-ab-test-setup, wizz-referral-program, wizz-tracking-audit]
       - id: wizz-tracking-audit
         when: "Auditar rastreamento de oferta de resposta direta. Modo implantação: pixel, CAPI, domínio verificado, eventos priorizados, UTM com ID, repasse do parâmetro nativo pelo checkout, higiene de nomenclatura, compra-teste por rota. Modo diagnóstico: qual transição do funil está furando, medição contra conversão, ROI verdadeiro contra falso, qual dado falta pra decidir."
         not_when:
           - "Plano de medição de SaaS ou produto instrumentado por evento de uso: é analytics-tracking."
           - "Decidir bid, orçamento ou estrutura de campanha: é paid-ads."
         rel:
-          pairs_with: [wizz-analytics-tracking, wizz-paid-ads]
           before: [wizz-page-cro]
+          pairs_with: [wizz-analytics-tracking, wizz-lowticket-trafego, wizz-paid-ads]
       # Módulo lowticket (src/modules/lowticket) — instaladas COM O MÓDULO, não
       # por skills-lib. O campo `module` é o gate: resolveSkillIds as ignora ao
       # copiar de src/skills-lib, e o router continua enxergando as entradas.
-      - id: wizz-lowticket-guia
-        module: lowticket
-        when: "Porta de entrada low ticket para leigo: 'não estou vendendo', 'por onde começo', 'anúncio não funciona'. Situa na jornada de 7 etapas e despacha."
-      - id: wizz-lowticket-metodologia
-        module: lowticket
-        when: "Roteador da base low ticket BR/PT: gatilho → um shard (diagnóstico de funil, bid cap, criativo, oferta, página, Instagram, player de VSL, upsell, copy, rastreamento, mineração). Carrega guardrails junto."
-        not_when:
-          - "SaaS, B2B, site de cliente, high ticket ou mentoria: os números não transferem."
       - id: wizz-lowticket-trafego
         module: lowticket
         when: "Diagnóstico e régua de campanha Meta de low ticket: estrutura 1-1-X, bid cap, régua de 3x, quando cortar, como escalar, ler print do gerenciador ou do funil."
         not_when:
           - "Google Ads institucional, campanha de marca, lead gen B2B."
           - "Escrever copy ou criativo: a skill lê número, não produz anúncio."
+        rel:
+          after: [wizz-lowticket-guia]
+          pairs_with: [wizz-lowticket-metodologia, wizz-lowticket-pagina, wizz-tracking-audit]
 
   architect:
     agent: wizz-agent-architect
@@ -447,27 +609,50 @@ areas:
     skills:
       - id: wizz-web-security
         when: "Auditar segurança web, OWASP, XSS/CSRF/injeção/SQLi, IDOR, headers, rate limit (IP+conta), CORS, clickjacking, vazamento de PII na resposta, antes de deploy/PR."
+        rel:
+          before: [security-audit-pentest]
+          pairs_with: [wizz-auth-and-secrets, wizz-database-and-deps, wizz-desktop-security]
       - id: wizz-auth-and-secrets
         when: "Auth (JWT/OAuth/SSO/Clerk), token no header vs URL, revogar no logout, enumeração de usuário, gestão de secrets, rotação de credenciais."
+        rel:
+          pairs_with: [wizz-web-security]
       - id: wizz-desktop-security
         when: "Segurança desktop/Electron (contextIsolation, code signing)."
+        rel:
+          pairs_with: [apple-design, wizz-web-security]
       - id: wizz-database-scaling
         when: "Banco lento, queries, índices, N+1, sharding, connection pool."
+        rel:
+          pairs_with: [wizz-caching-and-queues, wizz-supabase-postgres-best-practices]
       - id: wizz-caching-and-queues
         when: "Cache (Redis), filas (BullMQ/SQS/Kafka), jobs assíncronos."
+        rel:
+          pairs_with: [wizz-database-scaling]
       - id: wizz-infrastructure
         when: "Escala de infra: Kubernetes, auto-scaling, CDN, SLOs, load test."
+        rel:
+          pairs_with: [sentry-cli, wizz-cloud-and-infra]
       - id: wizz-cloud-and-infra
         when: "Custo de cloud: right-sizing, spot/reserved, S3 lifecycle, billing AWS/GCP."
+        rel:
+          pairs_with: [wizz-infrastructure]
       - id: wizz-database-and-deps
         when: "Dependências/packages, vulnerabilidades, npm audit."
+        rel:
+          pairs_with: [wizz-launch-readiness, wizz-web-security]
       - id: wizz-supabase-postgres-best-practices
         when: "Performance e boas práticas de Postgres/Supabase (queries, schema, RLS)."
+        rel:
+          pairs_with: [supabase, wizz-database-scaling]
       - id: wizz-ai-product-design
         when: "Construir/melhorar um agente ou produto de IA: escrever/revisar system prompt, definir persona/tom, guardrails e recusas, few-shot, chain-of-thought, orquestração multi-agente, handoff, detecção de frustração, generative UI, avaliar qualidade de saída. Base para desenhar os próprios agentes do método. 44 padrões (Owl-Listener, MIT)."
+        rel:
+          pairs_with: [enhance-prompt]
     mcps:
       - id: supabase
         when: "Operar Supabase de verdade: rodar SQL, migrations, inspecionar schema/RLS, logs. Default é READ-ONLY e escopado a um projeto (--read-only --project-id); para ESCREVER (migrations, mutações), o agente precisa remover conscientemente o --read-only desta entrada antes de usar — nunca por padrão silencioso."
+        rel:
+          pairs_with: [wizz-supabase-postgres-best-practices]
         server:
           command: npx
           # Pin de supply chain (2026-08-23): versão fixa; atualizar conscientemente.
@@ -480,6 +665,8 @@ areas:
         not_when:
           - "Projeto ainda não usa Sentry (sem SENTRY_DSN, sentry.properties ou '@sentry/' no package.json)."
           - "Fora de estágio de produção."
+        rel:
+          pairs_with: [wizz-infrastructure]
         check: "sentry-cli --version"
         # Pin de supply chain (2026-08-25): versão fixa; atualizar conscientemente.
         install: "npm install -g @sentry/cli@3.6.2"
@@ -488,6 +675,8 @@ areas:
         not_when:
           - "Registrar a decisão de arquitetura em si: isso é o wizz-architecture."
           - "Diagrama descartável de conversa: Mermaid inline já basta."
+        rel:
+          after: [wizz-implementation-planner]
         platform: [darwin, linux]
         # Origem: auditoria 2026-09-11, Parte 3.10, item 25. Pin de supply chain
         # (2026-09-12): tag de release v2.16.0, não main — upstream tem 155
@@ -508,20 +697,33 @@ areas:
     skills:
       - id: wizz-adversarial-reviewer
         when: "Passe único adversarial, ad hoc, fora de workflow — 'tear this apart' num trecho colado, sem contexto de projeto. Não confundir com wizz-review-adversarial-general (persona do 'Blind Hunter'; o prompt operacional vive em review-prompts/blind-hunter.md e nenhum workflow invoca a skill) nem com wizz-code-review (orquestrador bmm: 3 camadas paralelas + triagem, para review real de diff/PR)."
+        rel:
+          instead_of: [wizz-code-review]
       - id: security-audit-pentest
         when: "Auditoria/pentest de segurança do app inteiro — 'auditar segurança', 'pentest', 'encontrar vulnerabilidades', varredura antes de release. Só para teste de segurança AUTORIZADO (seus sistemas ou de clientes com permissão): ferramenta dual-use, nunca usar contra alvo sem autorização."
+        rel:
+          after: [wizz-web-security]
+          pairs_with: [strix, wizz-launch-readiness]
       - id: wizz-launch-readiness
         when: "Auditoria de prontidão pra lançamento (Pre-launch Audit), multi-área: técnico/build, segurança, SEO/descoberta, analytics/medição, conteúdo/copy/prova social, legal/LGPD, infra/deploy/rollback. Gatilhos: 'tá pronto pra lançar?', 'auditoria de pré-lançamento', 'checklist de release amplo', 'o que falta antes de ir pra produção'. Gate por estágio: só roda de verdade em mvp/production, e recusa educadamente em estágio de descoberta/ideação. Diagnostica e prioriza por severidade (bloqueia/alto/médio/ok), nunca corrige cego: aponta security-audit-pentest pra aprofundar segurança com prova de exploração e site-launch-kit pra executar a correção quando a superfície do achado é site. Resultado persiste numa seção datada do project-context.md."
         not_when:
           - "Estágio de descoberta/ideação: projeto ainda sem superfície construída pra auditar (sem project-context.md, ou stage 'prototype' vazio)."
           - "Correção de um achado isolado de site já identificado: nesse caso vá direto pra site-launch-kit."
         rel:
-          pairs_with: [site-launch-kit, security-audit-pentest]
+          pairs_with: [security-audit-pentest, site-launch-kit, wizz-database-and-deps]
+      - 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."
+        rel:
+          pairs_with: [wizz-launch-readiness, wizz-schema-markup]
       - id: wizz-agent-browser
         when: "Verificação visual/browser, preencher forms, screenshots, testar UI no navegador. CLI já instalado (não é MCP); browser SEMPRE via wizz-agent-browser, nunca Playwright."
+        rel:
+          pairs_with: [agent-browser]
     clis:
       - id: agent-browser
         when: "Dirigir um browser real pra E2E/verificação: navegar, clicar, preencher form, screenshot, console. É CLI, não MCP."
+        rel:
+          pairs_with: [wizz-agent-browser]
         check: "agent-browser --version"
         # Pin de supply chain (2026-08-23): versão fixa; atualizar conscientemente.
         install: "npm install -g agent-browser@0.34.0"
@@ -544,8 +746,14 @@ areas:
     skills:
       - id: wizz-inicio-de-projeto
         when: "Kickoff LEVE de engenharia: stack, personas, glossário, princípios, estrutura de pastas, checklist. Atalho sem cerimônia de PRD."
+        rel:
+          before: [wizz-implementation-planner]
       - id: wizz-implementation-planner
         when: "Plano técnico de implementação de site/app premium pós-direção aprovada. Pesquisa web/prior-art durante o planejamento usa a tool nativa WebSearch (sem custo/MCP metered — o MCP exa foi removido em 2026-08-25)."
+        rel:
+          after: [wizz-inicio-de-projeto]
+          before: [archify, wizz-quick-dev]
+          pairs_with: [wizz-document-project]
 
   # ── Áreas dev/produto (item 18 da auditoria de 2026-09-11, finding RT-H2):
   # "dev" era citado dezenas de vezes no método (router, maestro,
@@ -563,27 +771,47 @@ areas:
       - id: wizz-quick-dev
         module: bmm
         when: "DEV PONTUAL: ajuste, bug fix, feature única sem cerimônia de story. Fluxo unificado: clarificar → planejar → implementar → review → apresentar. É o destino padrão quando o router/maestro diz 'dev pontual'."
+        rel:
+          after: [wizz-implementation-planner, wizz-investigate]
       - id: wizz-dev-story
         module: bmm
         when: "Implementar UMA story específica com spec preenchida ('dev this story', 'implementa a próxima story do sprint')."
+        rel:
+          after: [wizz-create-story]
+          before: [wizz-code-review]
       - id: wizz-create-story
         module: bmm
         when: "Preparar story com todo o contexto de implementação ('cria a story', 'prepara a story'). Antes do dev, no gate de planejamento."
+        rel:
+          after: [wizz-prd, wizz-set-feature, wizz-sprint-planning]
+          before: [wizz-dev-story]
       - id: wizz-code-review
         module: bmm
         when: "Review de código real de diff/PR: 3 camadas paralelas (Blind Hunter, Edge Case, Verification Gap) + triagem. Diferente de wizz-adversarial-reviewer (passe único ad hoc, área qa)."
+        rel:
+          after: [wizz-dev-story]
+          instead_of: [wizz-adversarial-reviewer]
       - id: wizz-investigate
         module: bmm
         when: "Investigar bug/incidente, rastrear causa, construir modelo mental de uma área de código antes de mexer."
+        rel:
+          before: [wizz-quick-dev]
       - id: wizz-sprint-planning
         module: bmm
         when: "Gerar/atualizar o sprint plan que sequencia stories para implementação."
+        rel:
+          before: [wizz-create-story, wizz-retrospective]
+          pairs_with: [wizz-correct-course]
       - id: wizz-correct-course
         module: bmm
         when: "Mudança significativa durante o sprint: propor ajuste de curso ('correct course')."
+        rel:
+          pairs_with: [wizz-sprint-planning]
       - id: wizz-retrospective
         module: bmm
         when: "Review do trabalho concluído no epic (party mode)."
+        rel:
+          after: [wizz-sprint-planning]
 
   pm:
     agent: wizz-agent-pm
@@ -592,15 +820,27 @@ areas:
       - id: wizz-prd
         module: bmm
         when: "Criar, atualizar ou validar PRD ('cria o PRD', 'documento de requisitos', 'define o escopo'). Consolida os antigos create/edit/validate-prd (removidos em v7)."
+        rel:
+          after: [wizz-product-brief]
+          before: [wizz-create-story, wizz-set-feature]
+          pairs_with: [wizz-ux]
       - id: wizz-product-brief
         module: bmm
         when: "Criar, atualizar ou validar o brief do produto ('cria o brief'). Antes do PRD, no kickoff de produto."
+        rel:
+          after: [wizz-prfaq]
+          before: [wizz-prd]
       - id: wizz-prfaq
         module: bmm
         when: "Desafio Working Backwards PRFAQ para forjar conceito de produto ('cria a PRFAQ', 'work backwards')."
+        rel:
+          before: [wizz-product-brief]
       - id: wizz-set-feature
         module: bmm
         when: "Definir feature específica dentro do produto (análise de feature única)."
+        rel:
+          after: [wizz-prd]
+          before: [wizz-create-story]
 
   tech-writer:
     agent: wizz-agent-tech-writer
@@ -609,6 +849,8 @@ areas:
       - id: wizz-document-project
         module: bmm
         when: "Documentar o projeto: gerar/atualizar docs de arquitetura e estrutura para contexto de agentes e humanos."
+        rel:
+          pairs_with: [wizz-implementation-planner]
 
   ux-designer:
     agent: wizz-agent-ux-designer
@@ -617,6 +859,8 @@ areas:
       - id: wizz-ux
         module: bmm
         when: "Especificar experiência do usuário: fluxos, wireframes de conteúdo, user stories de UX (diferente da área designer, que constrói UI visual)."
+        rel:
+          pairs_with: [wizz-prd]
 
   memoria:
     agent: wizz-memoria
@@ -633,6 +877,8 @@ utility:
     when: "Nenhuma skill cobre o pedido: buscar/instalar no marketplace (npx skills find)."
   - id: enhance-prompt
     when: "Empacotar um briefing mais completo/estruturado pra mandar a outro agente ou skill."
+    rel:
+      pairs_with: [wizz-ai-product-design]
   - id: wizz-router
     when: "Roteador global/flat: descobre skills quando não se sabe a área; escala pro maestro se multi-área."
 

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

@@ -41,6 +41,7 @@ You are the leaf: the maestro demotes here for pointed work (bug, tweak, single-
 
 - If clarification reveals the request is actually **multi-goal / multi-area** (2+ top-level shippable deliverables, or it spans several areas), do not silently absorb it. That is clause 1: escalate regardless of how light each individual part looks. Surface it and propose escalating to `wizz-maestro` to orchestrate the sequence. Proceed solo only if the user confirms a narrowed single goal.
 - 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.
+- **Count those factors with the objective test** (canonical source: `_shared/complexity-signal.md`; same test the Diretor and the maestro apply). **When in doubt, the factor does NOT count.** *Multi-step* = the delivery is 2+ artifacts of different kinds (a batch of the same kind is ONE delivery). *Needs planning* = a scope or ordering decision is missing that the user has not made; "work that has internal steps" does not count, every task has internal steps. *Memorable artifact* = a reference document someone reopens later (PRD, story, spec, written plan or audit); a fix, a component or a refactor of one module is not. A **single delivery** and the **diagnosis of one specific mechanism** stay with you, however important they look; what escalates is the request of **open scope that the request itself does not delimit** ("how do I improve / reduce X" is that, a question with a single definable answer is not), and what escalates regardless of size is a **sensitive subsystem**: changing auth/sessions, payments/billing, permissions, or migrating data that already exists in production goes to the maestro even as a single delivery, because getting it wrong breaks something other than the delivery itself (people locked out, money charged twice, data lost). Running a test against one of those is not changing it. **Changing the product's code is yours even when the subject is visual** — a button colour, mobile spacing: the delivery is a commit, and `designer` decides the look without shipping the change.
 - 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)

package/src/modules/wizz/_shared/rel-protocol.md

@@ -0,0 +1,17 @@
+# Rel protocol (single source)
+
+# Read by the 8 area agents as the CANONICAL SOURCE of the paragraph below
+# (wizz-ads, wizz-copy, wizz-designer, wizz-growth, wizz-memoria, wizz-qa and
+# wizz-seo, plus wizz-social) and by wizz-maestro in its own variant. The
+# SKILL.md files do not include it automatically (an agent is a self-contained
+# folder copied verbatim), so editing here does NOT propagate on its own —
+# whoever edits this paragraph has to replicate it by hand in the 8 SKILL.md
+# files. `test/test-rel-protocol-consistency.js` compares the copies against
+# this block character by character and fails on any divergence.
+#
+# `evals/routing/run-routing-eval.mjs` also extracts this paragraph at runtime
+# to build the skill-discovery prompt: what the eval measures has to be the
+# rule the method actually ships, never a local summary (2026-09-18).
+# ---
+
+**Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first.

package/src/modules/wizz/_shared/video-pipeline.md

@@ -25,7 +25,7 @@
 | **Source B-roll / inserts: find real footage of what the script names** | `get-brolls` (darwin) |
 | Edit/cut recorded footage (cuts, selects, roughcut) | `buttercut` (darwin-arm64 only) |
 | Analyze an existing reference video (frames + transcription) | `claude-video` |
-| AI-generated video ad (Sora/Veo/Kling) + publish to Meta | `arcads` (ads area) |
+| AI-generated video/image (Veo/Kling/Wan), UGC / ad-ready style | `fal-video` (designer area; needs `FAL_KEY`) |
 
 ## Full chain (script → publishing)
 

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

@@ -20,7 +20,7 @@ You are Wizz's Ads. It plans campaigns, generates creative variations, and track
 
 ## How I work (global bridge)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`ads`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/ads.yaml` (already comes as the full `areas.ads` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.ads` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`), and `mcps:` (`claude mcp add <id>` with the `server` block). The examples below are a readable shortcut; the registry is the source of truth and picks up new additions automatically (e.g., `arcads` for generating video ads).
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`ads`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/ads.yaml` (already comes as the full `areas.ads` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.ads` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`), and `mcps:` (`claude mcp add <id>` with the `server` block). **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first. The examples below are a readable shortcut; the registry is the source of truth and picks up new additions automatically (e.g., `arcads` for generating video ads).
 - Campaign strategy, segmentation, bids, ROAS → `wizz-paid-ads`
 - Creative variations, headlines, ad copy → `wizz-ad-creative`
 - Tracking, conversions, UTMs, pixel → `wizz-analytics-tracking`

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

@@ -20,7 +20,7 @@ You are Wizz's Copy. It writes texts that sell, humanizes what sounds robotic, a
 
 ## How I work (global bridge)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`copy`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/copy.yaml` (already comes as the full `areas.copy` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.copy` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`), and `mcps:` (`claude mcp add <id>` with the `server` block). The examples below are a readable shortcut; the registry is the source of truth and picks up whatever gets added later.
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`copy`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/copy.yaml` (already comes as the full `areas.copy` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.copy` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`), and `mcps:` (`claude mcp add <id>` with the `server` block). **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first. The examples below are a readable shortcut; the registry is the source of truth and picks up whatever gets added later.
 - Page copy, headline, value proposition → `wizz-copywriting`
 - Email, sequence, nurture → `wizz-email-sequence`
 - Make text natural, remove the AI feel → `wizz-humanizer`

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

@@ -25,7 +25,7 @@ You are Wizz's Designer. It creates high-level interfaces and landing pages, sho
 
 ## How I work (bridge to global skills)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`designer`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/designer.yaml` (already comes as the full `areas.designer` block — skills/mcps/clis/references); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.designer` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), also read `{project-root}/_wizz/_config/registry/_shared.yaml`. Route by the `when:` field — `skills:` (invoke via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:` — e.g. `buttercut` is `darwin-arm64` only) and `mcps:` (propose `claude mcp add <id>` with the `server` block). **Entry points (skills):** offer only the 3 skills with `entry: true` (direction → wizz-decision-maker, building → wizz-ui-ux-pro-max, motion/assets → wizz-animate); the rest carry a `door:` field and only come in pulled by their layer's door or by an explicit user request — never offer the full list. The examples below are just a readable shortcut; the registry is the source of truth and picks up whatever gets added later (e.g. video tools: hyperframes, get-brolls, claude-video, buttercut, voicebox, ctc-align). **Video:** before choosing a tool, apply `_shared/video-pipeline.md` — HyperFrames draws the screens (silent visual, one scene per composition), Remotion assembles the film (audio, SFX, captions, frame timing via ctc-align); never position audio/captions in HyperFrames. **B-roll:** when the script names something real (a fact, a person, a product, a news item, a screen), the insert is sourced with `get-brolls`, not drawn — it searches the literal source, builds a Storyboard, and stops at a human approval gate you never sign for the user. Stock only enters if the user asks for stock.
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`designer`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/designer.yaml` (already comes as the full `areas.designer` block — skills/mcps/clis/references); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.designer` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), also read `{project-root}/_wizz/_config/registry/_shared.yaml`. Route by the `when:` field — `skills:` (invoke via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:` — e.g. `buttercut` is `darwin-arm64` only) and `mcps:` (propose `claude mcp add <id>` with the `server` block). **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first. **Entry points (skills):** offer only the 3 skills with `entry: true` (direction → wizz-decision-maker, building → wizz-ui-ux-pro-max, motion/assets → wizz-animate); the rest carry a `door:` field and only come in pulled by their layer's door or by an explicit user request — never offer the full list. The examples below are just a readable shortcut; the registry is the source of truth and picks up whatever gets added later (e.g. video tools: hyperframes, get-brolls, claude-video, buttercut, voicebox, ctc-align). **Video:** before choosing a tool, apply `_shared/video-pipeline.md` — HyperFrames draws the screens (silent visual, one scene per composition), Remotion assembles the film (audio, SFX, captions, frame timing via ctc-align); never position audio/captions in HyperFrames. **B-roll:** when the script names something real (a fact, a person, a product, a news item, a screen), the insert is sourced with `get-brolls`, not drawn — it searches the literal source, builds a Storyboard, and stops at a human approval gate you never sign for the user. Stock only enters if the user asks for stock.
 
 For every task, **go through the right door via the `Skill` tool** and bring the result in plain language:
 - Decide BEFORE building (brief, visual direction, motion/3D path) → `wizz-decision-maker` (pulls in wizz-taste-skill, wizz-motion-3d-director)

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

@@ -22,7 +22,7 @@ You are Wizz's Growth. It brings actionable marketing and conversion ideas, plan
 
 ## How I work (global bridge)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`growth`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/growth.yaml` (already comes as the full `areas.growth` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.growth` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`), and `mcps:` (`claude mcp add <id>` with the `server` block). The examples below are a readable shortcut; the registry is the source of truth and picks up new additions automatically (e.g., MCP `scrapling`).
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`growth`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/growth.yaml` (already comes as the full `areas.growth` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.growth` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`), and `mcps:` (`claude mcp add <id>` with the `server` block). **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first. The examples below are a readable shortcut; the registry is the source of truth and picks up new additions automatically (e.g., MCP `scrapling`).
 - Marketing ideas and strategy → `wizz-marketing-ideas`
 - Optimize page/funnel conversion → `wizz-page-cro`
 - Product/feature launch, go-to-market → `wizz-launch-strategy`

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

@@ -76,7 +76,8 @@ The Diretor (`wizz-router`) has already done the triage and handed it to you bec
    - `areas:` — `agent` (must match the menu's) and `skills:` (each with an `id` + short `when`). Instruct the agent to invoke the global skill(s) whose `when` matches the request.
    - `utility:` — cross-cutting skills (find-skills, enhance-prompt, wizz-router). Offer when it fits.
    - `mcps:` (per area) and `mcp_utility:` (cross-cutting) — MCP servers the area uses to actually ACT (e.g. architect→supabase, analyst→exa, util→context7; qa does NOT use a browser MCP — it's agent-browser via CLI). If the request needs real access to the tool and the MCP isn't active (`claude mcp list`), propose `claude mcp add <id> -- <command>` using the registry's `server` block (secrets via env/placeholder).
-   - `clis:` (per area) and `cli_utility:` (cross-cutting) — command-line tools the agent calls directly (neither a skill nor an MCP): e.g. qa→agent-browser; designer→hyperframes/get-brolls/claude-video/buttercut/voicebox (video); ads→arcads; growth→scrapling; seo→distribb. When the `when:` matches the request, offer the tool: run the `check:` to see if it's already installed; if not, show the `install:` (opt-in, never auto-run without confirming). Respect the `platform:` field — if present and it doesn't match the current OS/arch, DON'T offer it (e.g., `buttercut` is `darwin-arm64`, Apple Silicon only). Clone-and-run tools (buttercut/voicebox/arcads) install into the project; warn about heavy deps.
+   - `clis:` (per area) and `cli_utility:` (cross-cutting) — command-line tools the agent calls directly (neither a skill nor an MCP): e.g. qa→agent-browser; designer→hyperframes/get-brolls/claude-video/buttercut/voicebox/fal-video (video); growth→scrapling; seo→distribb; social→postiz. When the `when:` matches the request, offer the tool: run the `check:` to see if it's already installed; if not, show the `install:` (opt-in, never auto-run without confirming). Respect the `platform:` field — if present and it doesn't match the current OS/arch, DON'T offer it (e.g., `buttercut` is `darwin-arm64`, Apple Silicon only). Clone-and-run tools (buttercut/voicebox) install into the project; warn about heavy deps.
+   - `rel:` (on any entry) — **this is where the method knows that a request about A also needs C.** `pairs_with` (they go together), `before`/`after` (mandatory order) and `instead_of` (one or the other, not both). Every edge is reciprocal by construction: the schema validator rejects one-way edges, so the relation shows up whichever side the user enters from. As the multi-area orchestrator you are the biggest beneficiary of this — roughly a third of the edges cross areas (count them in the registry when you need the number; don't quote one from memory). When building the dispatch, follow the same order the area agents follow ([rel protocol](../../_shared/rel-protocol.md)): LIST every id the chosen entry's `rel` names — including the ones you don't recognise, which are exactly the point — resolve each id → area via the `ids:` map in `{project-root}/_wizz/_config/registry/index.yaml`, read that area's slice for its `when:`, and then either bring it in or discard it with a stated reason. A target in another area becomes a dispatch to THAT area's agent, and a `before` target sets the ORDER of the plan, not a parallel item. Never deliver only the half the user named when `rel` says the other half is missing: a related capability you never named is one the method lost.
    - `squads:` — advisory panels (run via `wizz-party-mode`). When the request calls for validation/strategy in a `domain`, run the squad BEFORE the agent in `advises` executes.
 
 In short: **the menu chooses the agent, the registry chooses the skill(s) and the squads.** Dev/product roles reuse the WIZZ agents; the agency ones are the `wizz-*`. Don't memorize agent names here — they come from the menu and the registry's `agent:` field.
@@ -90,6 +91,18 @@ In short: **the menu chooses the agent, the registry chooses the skill(s) and th
 3. **Planning** — can it go straight ahead, or does it need planning first?
 4. **Artifact + memory** — does it produce a deliverable worth recording in the cerebro?
 
+**How to count factors 2-4** (canonical source: `_shared/complexity-signal.md`; the same test the Diretor applies, so the two of you don't disagree about the same request). **When in doubt, the factor does NOT count.**
+
+- **Multi-step:** the final delivery is 2+ artifacts **of different kinds**. A batch of the same kind (3 CTA variants, 5 headlines, a 10-slide carousel) is ONE delivery.
+- **Needs planning:** a **scope or ordering** decision is missing that the user has not made. "Work that has internal steps" does not count.
+- **Memorable artifact:** a **reference document someone reopens later** (PRD, story, spec, written plan or audit). A delivered piece — post, headline, carousel, component, fix, answer — is not.
+
+Inside the 1-area branch, three shortcuts **demote on their own**, before counting any factor: a **question with a single definable answer**, a **single delivery**, and the **diagnosis of one specific mechanism** all go to the area agent. "How do I improve / reduce X" is not that question — it has no single answer. What stays with you is the request of **open scope that the request itself does not delimit** ("how do I improve the signup conversion rate", "the page gets visits and nobody buys"): there the scope has to be discovered first, and that is your work. What decides is not the size of the request, it is whether the request already states what the delivery is. **Two clauses cut across all of this** (canonical source: `_shared/complexity-signal.md`): a **sensitive subsystem** — changing auth/sessions, payments/billing, permissions, or migrating production data — is yours even as a single delivery of one area, because the blast radius of a mistake lands outside the delivery itself; and, the other way round, open scope stops being open when **one catalogue entry covers the whole outcome** and what leaves at the end is that entry's own deliverable ("a plan to reduce churn" is `wizz-churn-prevention`, "what to check before going live" is `site-launch-kit`) — that one goes to the area, not to you.
+
+**Changing the product's code is `dev`, even when the subject is visual** — the delivery is a commit. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
+
+**What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Ask of each edge: would the thing being handed over be incomplete without this? A sales page without the offer and the conversion structure is half a page (same artifact → escalates); a text post does not become a video job because of a `before: [get-brolls]` edge (different artifact → does not). `pairs_with` alone never escalates.
+
 Handoff rule:
 
 - **1 area and 0-1 of the remaining 3 factors (2-4 above) → demote:** send it to that area's agent (a one-off dev tweak → `wizz-quick-dev`; otherwise the area's `agent:`) or to a single skill. Don't orchestrate. Normally the Diretor wouldn't even call you in this case, but if it got here, demote it.

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

@@ -20,7 +20,7 @@ You are Wizz's Memória. It stores and retrieves the user's context across sessi
 
 ## How I work (global bridge)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`memoria`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/memoria.yaml` (already comes as the full `areas.memoria` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.memoria` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:`, and `mcps:` (`claude mcp add <id>` with the `server` block). The examples below are a readable shortcut; the registry is the source of truth and picks up whatever gets added later.
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`memoria`) lives in `skills-registry.yaml`. Resolve the **light slice for your area** first, `{project-root}/_wizz/_config/registry/memoria.yaml` (already comes as the full `areas.memoria` block); if it's missing (old install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.memoria` block there. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request via `when:` — `skills:` (via `Skill`), `clis:`, and `mcps:` (`claude mcp add <id>` with the `server` block). **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first. The examples below are a readable shortcut; the registry is the source of truth and picks up whatever gets added later.
 - View the project's current state → `cerebro` (`/ver`)
 - Save the session → `cerebro` (`/salvar`)
 - Record an architecture/product decision → `cerebro` (`/decisao`)

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

@@ -22,7 +22,7 @@ You are Wizz's QA. You come in **after wizz-agent-dev**: you take the finished c
 
 ## How I work (global bridge)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`qa`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/qa.yaml` (already comes as the full `areas.qa` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.qa` block inside it. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request by `when:` — `skills:` (via `Skill`) and `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`; e.g. `wizz-agent-browser` for browser verification — never Playwright). The examples below are a readable shortcut; the registry is the source of truth and picks up anything added later.
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`qa`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/qa.yaml` (already comes as the full `areas.qa` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.qa` block inside it. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request by `when:` — `skills:` (via `Skill`) and `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`; e.g. `wizz-agent-browser` for browser verification — never Playwright). The examples below are a readable shortcut; the registry is the source of truth and picks up anything added later. **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first.
 
 - Run the test suite and report what passed/failed → I run the project's tests and summarize.
 - Generate E2E tests and run critical flows → `wizz-qa-generate-e2e-tests`; for a real browser, use `wizz-agent-browser`.

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

@@ -20,7 +20,7 @@ You are Wizz's SEO. You audit, prioritize, and optimize for Google and for AI se
 
 ## How I work (global bridge)
 
-> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`seo`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/seo.yaml` (already comes as the full `areas.seo` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.seo` block inside it. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request by `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`) and `mcps:` (`claude mcp add <id>` with the `server` block). The examples below are a readable shortcut; the registry is the source of truth and picks up new additions automatically (e.g. `distribb`).
+> **Single source (registry) — ALWAYS read before the examples below:** the real list for your area (`seo`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/seo.yaml` (already comes as the full `areas.seo` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.seo` block inside it. If you need something cross-cutting (utility/mcp_utility/cli_utility/squads), read `{project-root}/_wizz/_config/registry/_shared.yaml`. Offer **everything that matches** the request by `when:` — `skills:` (via `Skill`), `clis:` (`check:` → if missing, show the `install:`, opt-in, respect `platform:`) and `mcps:` (`claude mcp add <id>` with the `server` block). **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first. The examples below are a readable shortcut; the registry is the source of truth and picks up new additions automatically (e.g. `distribb`).
 - Audit, why it's not ranking, technical issues → `wizz-seo-audit`
 - Show up in ChatGPT/Perplexity/AI Overviews → `wizz-ai-seo`
 - Structured data / rich results → `wizz-schema-markup`

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

@@ -43,7 +43,7 @@ Optional (when the topic calls for it): **Novelty** (just launched? determines F
 
 ## How I work (global bridge)
 
-> **Single source (registry) · ALWAYS read before the examples below:** the real list for your area (`social`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/social.yaml` (already comes as the full `areas.social` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.social` block inside it. Offer **everything that matches** the request by `when:`. `skills:` (via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:`, e.g. `buttercut` is `darwin-arm64` only) and `mcps:`. The video CLIs (hyperframes, get-brolls, claude-video, buttercut, voicebox) belong to the `designer` area; read `{project-root}/_wizz/_config/registry/designer.yaml` (or `_shared.yaml` for cross-cutting utility/mcp_utility/cli_utility/squads) to get their block. The examples below are a readable shortcut; the registry is the source of truth and picks up anything added later.
+> **Single source (registry) · ALWAYS read before the examples below:** the real list for your area (`social`) lives in `skills-registry.yaml`. Resolve first the **lightweight slice for your area**, `{project-root}/_wizz/_config/registry/social.yaml` (already comes as the full `areas.social` block); if it's missing (older install), fall back to the monolith in order `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` and find the `areas.social` block inside it. Offer **everything that matches** the request by `when:`. `skills:` (via `Skill`), `clis:` (run the `check:`; if missing, show the `install:`, opt-in; respect `platform:`, e.g. `buttercut` is `darwin-arm64` only) and `mcps:`. The video CLIs (hyperframes, get-brolls, claude-video, buttercut, voicebox) belong to the `designer` area; read `{project-root}/_wizz/_config/registry/designer.yaml` (or `_shared.yaml` for cross-cutting utility/mcp_utility/cli_utility/squads) to get their block. The examples below are a readable shortcut; the registry is the source of truth and picks up anything added later. **Follow `rel:` before answering.** An entry's `rel` (`pairs_with`, `before`, `after`, `instead_of`) is how the method knows that a request about A also needs C. Every edge is reciprocal by construction — the schema validator rejects one-way edges — so the relation shows up whichever side the user enters from. Do it in this order, before answering: (1) pick the entries whose `when:` matches the request; (2) LIST every id named in the `rel` of those entries — including the ids you do not recognise, which are exactly the point; (3) for each id outside YOUR slice, resolve id → area through the `ids:` map (id → area) in `{project-root}/_wizz/_config/registry/index.yaml` and read that area's slice to get its `when:` (a target marked `_shared` lives in `_shared.yaml`); (4) either bring it in or discard it with a stated reason. A related capability you never named is one the method lost: silence is the failure, not the discard. When the target is in ANOTHER area and shapes the SAME deliverable (the thing you are about to hand over is incomplete without it), say so and offer `wizz-maestro`, who coordinates areas — you never invoke the other area's agent yourself, and you never hand the request back to whoever delegated it to you (anti-loop). Tell the user what the related capability is instead of delivering only the half they asked for, and when the relation is `before`, say what has to come first.
 
 Script and content (you yourself, with the blueprint + skills):
 - Viral Reel/Short script, any format (hook, body, CTA) → apply the blueprint (Sections 1-11; Section 12 for the 3D-character format).

package/src/skills-lib/_shared/complexity-signal.md

@@ -1,14 +1,41 @@
-# Sinal de complexidade (fonte única)
-#
-# Lido por wizz-router (SKILL.md), wizz-maestro (SKILL.md) e wizz-quick-dev
-# (SKILL.md) como a FONTE CANÔNICA do parágrafo de regra abaixo. As SKILL.md
-# não fazem include automático dele (skills são pastas autocontidas copiadas
-# verbatim), então editar aqui NÃO propaga sozinho — quem editar este
-# parágrafo precisa replicar a mudança manualmente nas 3 SKILL.md (PT-BR
-# idêntico (após a normalização do teste: backticks, prefixo wizz-, "(você)") em wizz-router/wizz-maestro; tradução em inglês em
-# wizz-quick-dev). `test/test-dispatch-rule-consistency.js` compara o texto
-# do bloco (não só os números) contra as 3 cópias e falha em qualquer
-# divergência de wording, não só de limiar.
+# Complexity signal (single source)
+
+# Read by wizz-router (SKILL.md), wizz-maestro (SKILL.md) and wizz-quick-dev
+# (SKILL.md) as the CANONICAL SOURCE of the rule paragraph below. The SKILL.md
+# files do not include it automatically (skills are self-contained folders
+# copied verbatim), so editing here does NOT propagate on its own — whoever
+# edits this paragraph has to replicate the change by hand in the 3 SKILL.md
+# files. `test/test-dispatch-rule-consistency.js` compares the block's text
+# (not just the numbers) against the 3 copies and fails on any divergence of
+# wording, not only of threshold.
 # ---
 
-Regra de dispatch: SE 2+ áreas → maestro, sempre. SENÃO conte os 3 fatores restantes (multi-passo, precisa planejar, gera artefato memorável); 2+ fatores → maestro. A cláusula de área decide sozinha, sem somar com mais nada.
+Dispatch rule: IF 2+ areas → maestro, always. OTHERWISE count the 3 remaining factors (multi-step, needs planning, produces a memorable artifact); 2+ factors → maestro. The area clause decides on its own, without summing with anything else.
+
+What you count are the areas of the catalogue ENTRIES the request matches — never the topics named in the sentence. "Full audit of the site: performance, SEO, security, accessibility" names four topics and matches one entry (`wizz-launch-readiness`, qa), whose four legs are that single audit's own scope, not four deliverables: one area, so `agent:qa`. Counting nouns instead of entries is the most common way to over-escalate. (Owner's decision, 2026-09-19.)
+
+## How to count (added 2026-09-18)
+
+Written as bare labels, the 3 factors above were true of almost any request, and the measured result was escalating nearly everything to the maestro: in the eval's first trustworthy measurement (sonnet, 3 samples), 26% of the cases answered differently between samples and most failures were over-escalation. A factor without an objective test is not a rule, it is an impression. What follows is the test. **When in doubt, the factor does NOT count.**
+
+- **Multi-step:** the final delivery is 2+ artifacts **of different kinds**. A batch of the same kind (3 CTA variants, 5 headlines, a 10-slide carousel) is ONE delivery, not multi-step.
+- **Needs planning:** a **scope or ordering** decision is missing that the user has not made and you cannot make alone. "Work that has internal steps" does not count: every skill has internal steps.
+- **Memorable artifact:** the result is a **reference document someone reopens later** (PRD, story, spec, written plan, written audit). A delivered piece — post, headline, carousel, component, fix, answer to a question — is **not** a memorable artifact.
+
+**One clause overrides the three shortcuts below: the sensitive subsystem.** Changing authentication/sessions, payments/billing, permissions, or migrating data that already exists in production goes to the maestro even as a single delivery inside a single area. The test is not the size of the job, it is the blast radius of a mistake: if getting it wrong breaks something OTHER than the delivery itself — people locked out, money charged twice, data lost — then deciding what must not break, in which order, and how to roll back is part of the work, and that decision belongs to the Manager. Running a test against one of those subsystems is not changing it. (Owner's decision, 2026-09-18: this is why "refactor the auth module" and "implement magic-link login" are both the maestro's while other single dev deliveries are not.)
+
+**Three shortcuts that decide on their own, inside the 1-area branch, before counting any factor:**
+
+- **Question with a single definable answer** ("what guarantee period do I set?", "are the events being measured correctly?") → the area agent. Careful: "how do I improve / increase / reduce X" is **not** this question — it has no single answer, it is open scope, and it belongs to the maestro. What makes it a shortcut is that the answer fits in a recommendation, not that the sentence ends in a question mark.
+- **Single delivery** (one post, one headline, one carousel, one component, one adjustment, one refactor of one module) → the area agent, however important it looks.
+- **Diagnosis of one specific mechanism** ("where is it leaking between the click and the page?") → the area agent.
+
+**The counterpart, and this is what is left for the maestro:** a request **of open scope, which the request itself does not delimit** — "how do I improve the signup conversion rate", "the sales page gets plenty of visits and almost nobody buys", "my sales page converts badly, improve it". There the scope has to be discovered before anything is delivered, and discovering scope is the Manager's work. The deciding difference is not the size of the request, it is whether **the request already states what the delivery is**.
+
+**And the counterpart has one exception: a single entry already delimits the scope.** If the whole outcome being asked for fits the `when:` of ONE catalogue entry, and what leaves at the end is that entry's own deliverable — a plan, a recommendation, an audit — then the scope is not open, the catalogue delimited it, and the request goes to that entry's area. "A plan to reduce churn" is `wizz-churn-prevention`; "I want ChatGPT and Perplexity to cite us" is `wizz-ai-seo`; "what to check before going live" is `site-launch-kit`. It stops being the exception the moment delivering the outcome means changing what other areas own: "improve the signup conversion rate" ends up in copy, UI and code, so it comes back to the maestro through the area clause. Ask which single entry would deliver it whole — if it takes two, the scope really is open. (Owner's decision, 2026-09-18.)
+
+**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
+
+**What `rel` drags counts as an extra area when the related capability shapes the SAME deliverable.** Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas → maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because the social content skill declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. The question to ask about each edge is "would the thing I am about to hand over be incomplete without this?", not "is this related?".
+
+**The counter-example that looks like the sales page and is not:** "I want to set up a referral programme" is `agent:growth`. The invitation is another deliverable (an e-mail sequence ships on its own) and attribution cannot escalate at all, because `wizz-analytics-tracking` already lives in growth next to `wizz-referral-program`. So check where a dragged capability actually lives before counting it: **an id that also exists in the dragging entry's own area never adds an area**, even when it exists elsewhere too. It adds one only when it exists solely elsewhere. (Owner's decision, 2026-09-19.)

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

@@ -40,12 +40,38 @@ Assess the **Area**: how many areas does the request touch? The canonical area l
 
 **Dispatch rule:** IF 2+ areas → `wizz-maestro`, always. OTHERWISE count the 3 remaining factors (multi-step, needs planning, produces a memorable artifact); 2+ factors → `wizz-maestro`. The area clause decides on its own, without combining with anything else.
 
+**What you count are the areas of the catalogue ENTRIES the request matches — never the topics named in the sentence.** A request can name four subjects and still match one entry, and then it is one area. "Full audit of the site: performance, SEO, security, accessibility" names four topics and matches `wizz-launch-readiness` (qa), whose `when:` already spans build, security, SEO, analytics, content, legal and infra: those four legs are that single audit's own scope, not four deliverables, so the answer is `agent:qa`. Counting nouns instead of entries is the most common way to over-escalate. (Owner's decision, 2026-09-19.)
+
 - **2+ areas → `wizz-maestro`, always.** It's the Manager: coordinates agents across areas, sets up the sequence, upholds the memory duty. Invoke via `Skill` and **stop here**.
 - **1 area and 0-1 of the 3 factors → the AGENT for that area.** Find the area in `skills-registry.yaml` and invoke the block's `agent:` (e.g.: `designer → wizz-designer`, `seo → wizz-seo`, one-off dev → `wizz-quick-dev`). **Stop here**: the agent pulls in the skills/clis/mcps. You do **not** fire standalone skills.
 - **1 area and 2+ of the 3 factors → `wizz-maestro` too.** Multi-step + needs planning + memorable artifact combined indicate that even within 1 area the work requires coordination.
 
 > An area agent only covers its own area. 2+ areas require coordination = the maestro's job; the area clause decides on its own, without combining with anything else.
 
+**How to count the 3 factors** (canonical source: `_shared/complexity-signal.md`). Written as vague labels, the 3 factors are true of almost any request, and the measured result was escalating nearly everything to the maestro. A factor without an objective test is not a rule, it is an impression. **When in doubt, the factor does NOT count.**
+
+- **Multi-step:** the final delivery is 2+ artifacts **of different kinds**. A batch of the same kind (3 CTA variants, 5 headlines, a 10-slide carousel) is ONE delivery, not multi-step.
+- **Needs planning:** a **scope or ordering** decision is missing that the user has not made and you cannot make alone. "Work that has internal steps" does not count: every skill has internal steps.
+- **Memorable artifact:** the result is a **reference document someone reopens later** (PRD, story, spec, written plan, written audit). A delivered piece — post, headline, carousel, component, fix, answer to a question — is **not** a memorable artifact.
+
+**One clause overrides the three shortcuts below: the sensitive subsystem.** Changing authentication/sessions, payments/billing, permissions, or migrating data that already exists in production goes to the maestro even as a single delivery inside a single area. The test is not the size of the job, it is the blast radius of a mistake: if getting it wrong breaks something OTHER than the delivery itself — people locked out, money charged twice, data lost — then deciding what must not break, in which order, and how to roll back is part of the work, and that decision belongs to the Manager. Running a test against one of those subsystems is not changing it. (Owner's decision, 2026-09-18: this is why "refactor the auth module" and "implement magic-link login" are both the maestro's while other single dev deliveries are not.)
+
+**Three shortcuts that decide on their own, inside the 1-area branch, before counting any factor:**
+
+- **Question with a single definable answer** ("what guarantee period do I set?", "are the events being measured correctly?") → the area agent. Careful: "how do I improve / increase / reduce X" is **not** this question — it has no single answer, it is open scope, and it belongs to the maestro. What makes it a shortcut is that the answer fits in a recommendation, not that the sentence ends in a question mark.
+- **Single delivery** (one post, one headline, one carousel, one component, one adjustment, one refactor of one module) → the area agent, however important it looks.
+- **Diagnosis of one specific mechanism** ("where is it leaking between the click and the page?") → the area agent.
+
+**The counterpart, and this is what is left for the maestro:** a request **of open scope, which the request itself does not delimit** — "how do I improve the signup conversion rate", "the sales page gets plenty of visits and almost nobody buys", "my sales page converts badly, improve it". There the scope has to be discovered before anything is delivered, and discovering scope is the Manager's work. The deciding difference is not the size of the request, it is whether **the request already states what the delivery is**.
+
+**And the counterpart has one exception: a single entry already delimits the scope.** If the whole outcome being asked for fits the `when:` of ONE catalogue entry, and what leaves at the end is that entry's own deliverable — a plan, a recommendation, an audit — then the scope is not open, the catalogue delimited it, and the request goes to that entry's area. "A plan to reduce churn" is `wizz-churn-prevention`; "I want ChatGPT and Perplexity to cite us" is `wizz-ai-seo`; "what to check before going live" is `site-launch-kit`. It stops being the exception the moment delivering the outcome means changing what other areas own: "improve the signup conversion rate" ends up in copy, UI and code, so it comes back to the maestro through the area clause. Ask which single entry would deliver it whole — if it takes two, the scope really is open. (Owner's decision, 2026-09-18.)
+
+**Changing the product's code is `dev`, even when the subject is visual.** "Adjust the secondary button's colour", "fix the mobile spacing": the delivery is a commit, so it is the dev area — `designer` decides what the look should be, it does not ship the change. Ask which artifact leaves at the end: a file in the repo → dev; a decision, a spec or a piece of art → the area that owns it.
+
+**The area count includes what `rel` drags, when the related capability shapes the SAME deliverable.** Before deciding "1 area", look at the `rel` of the entry that matched, and ask of each edge: **would the thing I am about to hand over be incomplete without this?** — not "is this related?". Writing the copy of a sales page without the offer and without the conversion structure delivers half a page: offer, copy and conversion are the same artifact, so that is 2 areas, hence maestro. What does NOT count is an adjacent capability that would produce a **different** artifact: a plain text post for LinkedIn does not need video capture just because `wizz-social-content` declares `before: [get-brolls]` — the b-roll would be another deliverable, not part of this one. `pairs_with` alone never escalates: it is neighbourhood, not dependency. Every edge is reciprocal by construction (the schema validator rejects one-way edges), so the relation shows up whichever side the user enters from. Resolve id → area via the `ids:` map in `{project-root}/_wizz/_config/registry/index.yaml`; outside a Wizz project, via `skills-registry.yaml` itself.
+
+**A referral programme is the counter-example, and it earns its place here because it looks like the sales page and is not.** "I want to set up a referral programme" is `agent:growth`, not the maestro. The invitation is another deliverable — an e-mail sequence is written, reviewed and shipped on its own — and attribution cannot escalate at all, because `wizz-analytics-tracking` already lives in growth, alongside `wizz-referral-program`. So before counting a dragged capability as a second area, check where it actually lives: **an id that also exists in the dragging entry's own area never adds an area**, even when it exists in another one too (`wizz-analytics-tracking` is in growth AND in ads; dragged from growth it stays growth). It adds an area only when it exists solely elsewhere. (Owner's decision, 2026-09-19, after the measurement showed the model applying this correctly while the written example claimed the opposite.)
+
 **Capability discovery (index, not a delegation shortcut):** the [flat routing table](references/routing-table-flat.md) can also be consulted here, inside a Wizz project, when the request doesn't name the right capability (e.g. "I want a carousel" → the index points to `wizz-canvas-design`). It only serves to find the capability's name; delivery still goes through the normal dispatch above (area agent / maestro) — never fire the skill directly from the table inside a Wizz project.
 
 **Calibrated edge examples** (from the evals dataset, `evals/routing/dataset.json`):

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

@@ -16,6 +16,8 @@ Use this table to map skills/CLIs/MCPs directly **outside a Wizz project** (no `
 | Dependencies, packages, vulnerabilities, npm audit | `wizz-database-and-deps` | 2 |
 | Security, XSS, CSRF, SQLi, IDOR, OWASP, rate limit, CORS, clickjacking, PII in the response, user enumeration, headers | `wizz-web-security` + `wizz-auth-and-secrets` | 1 |
 | Full-app security audit/pentest, "audit security", "pentest", "find vulnerabilities", pre-release scan | `security-audit-pentest` | 1 |
+| **Autonomous, offensive** pentest that actually runs the app and proves each finding with a real PoC | CLI `strix` (qa registry). CONDITIONAL, never the default: only on an app the user owns/is authorized to test, and only when they ask for validated exploitation rather than a review. Start from `security-audit-pentest` | 2 |
+| Error monitoring, crash/exception triage, releases and source maps in Sentry | CLI `sentry-cli` (architect registry). CONDITIONAL: only if the project ALREADY uses Sentry (`SENTRY_DSN` in env, `sentry.properties`, or `@sentry/` in package.json) and it's at production stage — never propose adopting Sentry from this row | 2 |
 | Launch-readiness audit, "is it ready to launch?", broad release checklist (technical, security, SEO, analytics, content, legal, infra), "what's missing before going to production" | `wizz-launch-readiness` | 1 |
 | Desktop, Electron, contextIsolation, code signing | `wizz-desktop-security` | 2 |
 
@@ -27,6 +29,7 @@ Use this table to map skills/CLIs/MCPs directly **outside a Wizz project** (no `
 | New feature, bug fix, TDD, tests, coverage | direct execution with TDD (global rules) and end-to-end verification at the end | 1 |
 | Broken build, TypeScript errors, lint, CI | direct execution (minimal fix until the build is green) | 2 |
 | Architecture, system design, technical decision, technical plan, breakdown, handoff | `wizz-implementation-planner` | 1 |
+| DRAW the architecture/workflow/sequence/dataflow/state as a navigable validated diagram (HTML+SVG, accepts Mermaid) | CLI `archify` (architect registry) — the rendering step, after the decision is made with `wizz-implementation-planner` | 2 |
 | Critical flow, E2E, visual browser verification | `wizz-agent-browser` | 2 |
 | SQL, schema, migrations, Supabase, RLS, query performance | `wizz-supabase-postgres-best-practices` + `wizz-database-scaling` | 1 |
 | Dead code, cleanup, refactoring | direct execution + `wizz-adversarial-reviewer` on review | 2 |
@@ -37,7 +40,10 @@ Use this table to map skills/CLIs/MCPs directly **outside a Wizz project** (no `
 
 | Intent / keywords | Skills to offer | Priority |
 |---|---|---|
+| Visual brief at kickoff, "what should this look like", deciding direction BEFORE building | `wizz-decision-maker` (designer's direction door: 6 aesthetic decisions + 3 logical ones) + `wizz-taste-skill` | 1 |
 | Design, UI, visual, component, style, palette, typography, design system | `wizz-ui-ux-pro-max` + `wizz-ui-component-curator` | 1 |
+| Turn a design into React/Vite components (Stitch MCP output) | `wizz-react-components` | 2 |
+| Review/audit NATIVE UI (iOS/macOS: SwiftUI, Flutter, React Native, Tauri, Electron) against the Apple HIG and Liquid Glass | CLI `apple-design` (designer registry) — covers what `wizz-taste-skill` declares out of scope; for web UI it's `wizz-ui-ux-pro-max` instead | 2 |
 | Landing page, hero, motion, 3D animation, conversion, visual CRO | `wizz-premium-landing-ui-researcher` | 1 |
 | Design quality, anti-slop, visual taste, aesthetics, critical eye | `wizz-taste-skill` (if installed) | 1 |
 | Frontend rules, deterministic UI code, 44 rules, frontend audit | `wizz-impeccable` (if installed) | 2 |
@@ -50,7 +56,7 @@ Use this table to map skills/CLIs/MCPs directly **outside a Wizz project** (no `
 | Word-by-word timestamps for TTS narration (sync captions/cuts/animation with speech) | `ctc-align` (designer registry; single source of timing, replaces Whisper) | 2 |
 | **Find B-roll / inserts / cutaways / supporting footage** for a video or Reel (real footage of the fact, person, product, news item or screen the script names; YouTube/Instagram/TikTok/Pexels/Pixabay/Commons/NASA) | CLI `get-brolls` (designer registry; **macOS**, global `skills add` + its own `install.sh`; needs ffmpeg with drawtext, Node 22+, Python 3.11+). Ends in a Storyboard the HUMAN approves — the agent never self-approves. Stock only when the user explicitly asks for stock | 1 |
 | **Edit/cut video** (cuts, selects, roughcut) | CLI `buttercut` (designer registry; **Apple Silicon only**, clone-and-run in the project, heavy deps) | 1 |
-| Generate an AI video ad/image (Sora/Veo/Kling) + publish to Meta | CLI `arcads` (`ads` registry; git clone + Arcads API key) | 1 |
+| Generate an AI video/image (Veo/Kling/Wan), UGC / ad-ready style | CLI `fal-video` (designer registry; official `@fal-ai/client`, needs `FAL_KEY` in `.env`). Replaced the old arcads entry: same use case, 50-95% cheaper per video, no heavy clone-and-run | 1 |
 | Analyze/understand an existing video (frames + transcription) | CLI `claude-video` (designer registry; `npx skills add bradautomates/claude-video`) | 2 |
 | Narration / voice / TTS / voice cloning for video | CLI `voicebox` (designer registry; local app with MCP endpoint) | 2 |
 | Research components compatible with the project | `wizz-ui-component-curator` (demos, code, and public registries with evidence) | 1 |
@@ -67,10 +73,15 @@ Use this table to map skills/CLIs/MCPs directly **outside a Wizz project** (no `
 | Price, plans, pricing, monetization | `wizz-pricing-strategy` + `wizz-paywall-upgrade-cro` | 1 |
 | Churn, retention, cancellation, NPS | `wizz-churn-prevention` + `wizz-revops` | 1 |
 | Page conversion, CRO, funnel optimization | `wizz-page-cro` + `wizz-copywriting` + `wizz-form-cro` | 1 |
+| Popup, modal, exit intent, interstitial | `wizz-popup-cro` | 2 |
+| **LOW TICKET (BR/PT), beginner selling a cheap product:** "I'm not selling", "where do I start", "my ad doesn't work", "how much do I charge" | `wizz-lowticket-guia` (entry door — places them on the 7-step journey and dispatches) | 1 |
+| Low ticket specifics once the area is known: Meta campaign ruler, 1-1-X, bid cap, when to cut/scale (`wizz-lowticket-trafego`); page, VSL, creative script, headline (`wizz-lowticket-metodologia`); post-checkout upsell/downsell ladder (`wizz-lowticket-funil`); sales-page speed, connect rate, pixel order, LCP/TTFB/CLS (`wizz-lowticket-pagina`); mining and judging a competitor's offer (`wizz-lowticket-minerador`) | the shard above; enter through `wizz-lowticket-guia` when unsure. **Not for SaaS, B2B, client sites, high ticket or coaching — the numbers don't transfer** | 1 |
 | Signup, onboarding, user activation | `wizz-signup-flow-cro` + `wizz-onboarding-cro` | 1 |
 | SEO, Google, search, AI search, LLM SEO | `wizz-seo-audit` + `wizz-ai-seo` + `wizz-schema-markup` + `wizz-programmatic-seo` + `wizz-site-architecture` | 1 |
+| EXECUTE the SEO distribution: publish articles, build backlinks through the Distribb network, connect Search Console, autopublish news | CLI `distribb` (seo registry) — the doing half; the strategy half is the SEO row above | 2 |
 | Competitor comparison, alternatives page, war room | `wizz-competitor-alternatives` | 2 |
 | Content, social media, newsletter, threads | `wizz-content-strategy` + `wizz-social-content` + `wizz-copy-editing` | 2 |
+| Actually PUBLISH/schedule to social networks (30+ integrations), not write it | CLI `postiz` (social registry; needs auth). Separates "generate" (Wizz skills above) from "publish" | 2 |
 | Cold email, B2B outbound, prospecting | `wizz-cold-email` | 2 |
 | Referral, referrals, affiliate program | `wizz-referral-program` | 2 |
 | Sales material, pitch, deck, proposal | `wizz-sales-enablement` | 2 |
@@ -80,6 +91,7 @@ Use this table to map skills/CLIs/MCPs directly **outside a Wizz project** (no `
 | Offer audience research, VoC, angle matrix, info-product lexicon | `pesquisa-de-publico-do-piva` | 1 |
 | Forge an offer, create an irresistible offer, unique mechanism, bonus, guarantee | `wizz-offer-forge` + `wizz-pricing-strategy` | 1 |
 | Market research, competitive intelligence | `deep-research` (external plugin — only if installed) | 2 |
+| Scrape/crawl the web for market research, lead prospecting or competitive intel (anti-bot bypass, adaptive parsing) | MCP `scrapling` (growth registry) — the collection layer under the research rows above | 2 |
 
 ## Context and Memory
 

package/tools/hooks/wizz-router-enforce.js

@@ -123,9 +123,10 @@ function findWizzRoot(startDir) {
 function buildContext(isWizzProject) {
   if (isWizzProject) {
     return (
-      '🎛️ Projeto Wizz: NÃO invoque wizz-router. 2+ áreas → sempre Skill `wizz-maestro`. ' +
+      '🎛️ Projeto Wizz: NÃO invoque wizz-router. 2+ áreas → `wizz-maestro`. ' +
       '1 área: 2+ fatores (multi-passo, planejar, artefato memorável) → `wizz-maestro`; ' +
-      'senão → Skill do agente da área (ex: wizz-designer, wizz-quick-dev). ' +
+      'senão → Skill da área (wizz-designer, wizz-quick-dev). ' +
+      'Auth/pagamento/permissão/migração → maestro. ' +
       'Personas são skills, não subagent_type; Agent usa tipos disponíveis wizz-exec-*' +
       '; difícil → wizz-exec-strong (ESCALAR → ultra). Trivial → direto.'
     );

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

@@ -92,7 +92,9 @@ const SLICE_HEADER =
 /**
  * Slice the parsed registry into `_wizz/_config/registry/`:
  *   - index.yaml: version + areas (only `agent`/`summary`) — a lightweight
- *     area→agent map for the maestro to route without loading full skill lists.
+ *     area→agent map for the maestro to route without loading full skill lists
+ *     — plus `ids:`, the INVERSE map (id → area) that makes a cross-area `rel`
+ *     edge dereferenceable in one hop instead of scanning every slice.
  *   - <area>.yaml: the full block for that area (skills/mcps/clis/references),
  *     wrapped as `area: <name>` + the area's own fields, for the area agent
  *     that owns it to read directly instead of the monolith.
@@ -116,8 +118,31 @@ async function generateRegistrySlices(registry, registryDir, trackFile) {
   for (const [name, area] of Object.entries(areas)) {
     indexAreas[name] = { agent: area && area.agent, summary: area && area.summary };
   }
+
+  // id → área, o índice INVERSO. Sem ele uma aresta `rel` cross-área é
+  // indereferenciável em runtime: o agente lê a fatia da própria área, vê
+  // `pairs_with: [wizz-copywriting]` e não tem como saber que isso mora em
+  // `copy.yaml` sem abrir as 15 fatias até achar. Com o mapa é um hop.
+  // As skills do módulo lowticket existem em mais de uma área; a primeira
+  // ocorrência ganha, e qualquer fatia serve porque o `when` é o que muda,
+  // não a skill.
+  const idToArea = {};
+  for (const [name, area] of Object.entries(areas)) {
+    if (!area) continue;
+    for (const key of ['skills', 'mcps', 'clis']) {
+      for (const entry of area[key] || []) {
+        if (entry && entry.id && !(entry.id in idToArea)) idToArea[entry.id] = name;
+      }
+    }
+  }
+  for (const key of ['utility', 'mcp_utility', 'cli_utility']) {
+    for (const entry of (registry && registry[key]) || []) {
+      if (entry && entry.id && !(entry.id in idToArea)) idToArea[entry.id] = '_shared';
+    }
+  }
+
   const indexPath = path.join(registryDir, 'index.yaml');
-  await fs.writeFile(indexPath, SLICE_HEADER + yaml.stringify({ version: registry && registry.version, areas: indexAreas }));
+  await fs.writeFile(indexPath, SLICE_HEADER + yaml.stringify({ version: registry && registry.version, areas: indexAreas, ids: idToArea }));
   trackFile(indexPath);
 
   for (const [name, area] of Object.entries(areas)) {