wizz-method 1.4.0 → 1.5.0

package/src/skills-lib/premium-landing-ui-researcher/references/audit-protocol.md

@@ -0,0 +1,124 @@
+## Audit Protocol
+
+O Source-First Protocol cuida do **início** (curar fontes maduras antes de implementar). O Audit Protocol cuida do **fim** (validar qualidade antes de declarar a landing pronta).
+
+Aplicar 3 passes em ordem. Cada um pega uma classe de problema diferente: usar os dois primeiros é redundante apenas em 60% dos casos; nos outros 40% um pega o que o outro deixou passar.
+
+### Pass 1: Taste Skill (cedo, antes da implementação completa)
+
+**Quando aplicar:** logo depois da Fase 5 do Source-First Protocol, quando você tem mockup/wireframe das seções ou primeira versão do hero implementada. Idealmente ainda dá tempo de trocar de componente sem custo alto.
+
+**Fonte:** `https://github.com/Leonxlnx/taste-skill.git`
+
+**Ângulo:** detector anti-AI-generic. Pergunta-chave: *"Esse layout poderia ser de qualquer SaaS genérico, ou tem assinatura autoral?"*
+
+**O que procurar e marcar como problema:**
+
+- Hero com "headline grande + subtítulo + 2 CTAs side-by-side" sem identidade própria
+- Features em grid 3-col com ícones decorativos cute (estilo "✨ Fast 🚀 Reliable 🔥 Secure")
+- Gradientes coloridos saturados sem propósito (purple-to-pink, blue-to-cyan padrão Tailwind)
+- Copy de IA: "revolutionize your workflow", "supercharge your business", "10x your results"
+- Layout simétrico perfeito sem tensão editorial
+- Bordas arredondadas excessivas (`rounded-3xl` em tudo)
+- Card stacks com shadow padrão `shadow-xl` Tailwind
+- Emoji decorativo em qualquer lugar que não seja microcopy de status
+- Testimonial cards genéricos com avatar redondo + nome + cargo + frase entre aspas
+- Pricing cards com badge "Most Popular" centralizado e gradiente
+
+**Saída do pass:** lista de até 5 pontos onde a landing parece template, com sugestão de **substituição** para cada um (componente de fonte autorizada, decisão editorial, ou remoção). Apresentar ao usuário antes de prosseguir.
+
+### Pass 2: Impeccable (tarde, com tokens e conteúdo reais)
+
+**Quando aplicar:** depois da implementação estar montada com tokens da marca, tipografia real, imagens/mockups reais. Pega problemas que só aparecem quando o componente está vivo, não em wireframe.
+
+**Fonte:** `https://github.com/pbakaus/impeccable.git`
+
+**Ângulo:** bagagem de design clássico. Pergunta-chave: *"Isso parece feito por um designer sênior com 10+ anos de bagagem editorial?"*
+
+**O que procurar e marcar como problema:**
+
+- **Spacing**: padding/margin inconsistente entre seções (24px aqui, 28px ali, 32px em outra). Definir e seguir uma escala (4/8/12/16/24/32/48/64/96/128)
+- **Hierarchy**: títulos competindo entre si por peso/tamanho. H1, H2, H3 devem ter contraste claro
+- **Leading**: `line-height` muito apertado em body (<1.5) ou muito largo em headlines (>1.15)
+- **Tracking**: letter-spacing wrong em maiúsculas pequenas (mono labels precisam mais tracking, ~0.18em)
+- **Optical alignment**: ícones com peso visual diferente do texto adjacente, números mono não monoespaçados na vertical
+- **Ritmo vertical**: scroll sem respiração (seção atrás de seção sem ar) ou com buracos enormes inexplicáveis
+- **Color hierarchy**: 5+ tons cinza para texto sem justificativa, accent usado em coisas que não são acionáveis
+- **Image cropping**: thumbnails com aspect ratio inconsistente entre cards
+- **Contraste tipográfico**: títulos heavy + body também heavy (faltou um light/regular pra criar contraste)
+- **Edge cases**: o que acontece quando o nome do projeto tem 4 palavras vs 1? E quando a descrição tem 2 linhas vs 4?
+- **Focus states**: o tab order entrega uma sequência editorial ou pula entre seções caoticamente?
+
+**Saída do pass:** lista de até 7 ajustes finos com **antes/depois** específicos (ex: "Hero subhead: trocar leading 1.1 → 1.3" / "Cards grid: alinhar baseline da numeração mono com baseline da headline do card").
+
+### Pass 3: Cross-check com referências
+
+**Quando aplicar:** depois dos passes 1 e 2, com a landing visualmente refinada.
+
+**Como usar agent-browser neste pass (ferramenta padrão):**
+
+agent-browser navega autonomamente em Chrome via CDP e devolve **accessibility tree compacto com refs `@eN`** (~200-400 tokens), não depende de screenshots. Skill instalada via `npm install -g agent-browser` (repo: https://github.com/vercel-labs/agent-browser). Para ver o core skill da CLI: `agent-browser skills get core`.
+
+Loop padrão:
+```bash
+agent-browser open <url>        # 1. abre a página
+agent-browser snapshot -i       # 2. lê estrutura (interactive elements)
+agent-browser get text @e1      # 3. inspeciona um nó específico
+agent-browser eval "<js>"       # 4. mede tokens (computed styles, etc.)
+```
+
+**O que fazer:**
+
+1. **Abrir a landing/dashboard** com `agent-browser open <url>` e capturar snapshot textual de cada seção crítica via `snapshot -i -s "<seletor>"` (escopo CSS).
+2. **Abrir 1-2 referências** da direção aprovada na mesma sessão (`open` + `snapshot -i`): Linear, Stripe, Beli, Copilot Money etc, conforme o público.
+3. **Comparar via accessibility tree + computed styles** (`get styles @eN` ou `eval "getComputedStyle(...)"`):
+   - hierarquia tipográfica (tamanhos, pesos, tracking)
+   - escala de radius e shadow
+   - densidade vertical (padding/margin entre seções)
+   - estados interativos (focus visible, contraste, tab order)
+4. **Screenshot é opcional**: só use `agent-browser screenshot path.png` quando precisar de confirmação visual de algo que o accessibility tree não captura (atmosfera, gradientes, motion frozen).
+5. Pergunta-chave: *"Está no mesmo degrau de qualidade visual ou ainda parece um nível abaixo?"*
+
+**Diagnóstico:**
+
+- Se a diferença for **gosto/direção** (escolhas conscientes de marca) → ok, manter
+- Se a diferença for **execução** (a referência tem polish que falta na sua) → voltar pro Source-First e buscar o componente que falta
+- Se a diferença for **fluidez de motion** → revisar timing, easing, escala e composição das animações (provavelmente faltou aplicar Design Motion Principles)
+- Se a diferença for **densidade visual** (referência mais espaçada e respira mais) → cortar elementos, não adicionar
+
+**Saída do pass:** veredicto curto: "pronta", "precisa de 1 pass mais (passe X)", ou "precisa voltar pro Source-First por causa de Y".
+
+> **Regra**: agent-browser navega via accessibility tree (texto) por padrão. **Não tirar screenshots por reflexo**: é overhead desnecessário. Só capturar imagem quando o tree não responde a pergunta (ex: comparar atmosfera visual entre 2 sites).
+
+### Pass 4: Acessibilidade e performance (sempre, antes de entregar)
+
+Não é gosto, é qualidade técnica. Verificar:
+
+- Contraste AA em todos os textos (mínimo 4.5:1 para body, 3:1 para large text)
+- Tab order coerente, focus visible em todos os elementos clicáveis
+- `prefers-reduced-motion` respeitado (3D off, animações simples)
+- Mobile: hero estático funciona, scroll horizontal vira vertical, sem cursor custom
+- Lighthouse: Desktop ≥ 90 Performance, 100 Accessibility, 100 SEO. Mobile ≥ 80 Performance, 100 Accessibility
+- LCP < 2.5s, CLS < 0.1, INP < 200ms
+- Bundle 3D faz lazy load (não bloqueia LCP)
+
+### Ordem e custo de cada pass
+
+| Pass | Quando | Custo de ajuste | Frequência |
+|---|---|---|---|
+| 1. Taste Skill | Wireframe / hero primeiro | Baixo (ainda dá pra trocar componente) | Sempre |
+| 2. Impeccable | Implementação com tokens reais | Médio (CSS fino) | Sempre |
+| 3. Cross-check | Visual final | Variável | Sempre |
+| 4. Acessibilidade + Perf | Antes de entregar | Médio-alto (pode exigir refactor) | Sempre |
+
+### Quando pular um pass
+
+**Nunca pular sem declarar ao usuário.** Casos onde faz sentido pular:
+
+- Pass 1 (Taste): pular se a direção visual veio inteira de uma referência específica que o usuário aprovou (ex: "clone exato do Everswap"): nesse caso, taste já foi decidido upstream
+- Pass 2 (Impeccable): pular se a landing for v0 throwaway / wireframe interno, não entrega real
+- Pass 3 (Cross-check): pular se não há referência pública disponível
+- Pass 4 (Acessibilidade): **nunca pular**
+
+Em qualquer pulada, declarar ao usuário: "vou pular o pass X porque Y, ok?". Nunca pular silenciosamente.
+

package/src/skills-lib/premium-landing-ui-researcher/references/component-sources.md

@@ -0,0 +1,336 @@
+## Source Access Strategy
+
+Priorizar fontes gratuitas, open source, públicas, registry-based ou fornecidas pelo usuário.
+
+Não depender de fontes pagas como parte central do fluxo.
+
+Fluxo recomendado de pesquisa:
+
+1. 21st.dev via MCP/API (`mcp__magic__*`), quando disponível;
+2. v0.app community (WebFetch, catálogo de referência, sem API key);
+3. repositórios open source autorizados: cache central em `~/.claude/design-sources/`;
+4. registries shadcn públicos;
+5. fontes de taste/motion (Reference Sources);
+6. fontes visuais abertas (Visual Inspiration Sources);
+7. referências enviadas pelo usuário;
+8. hipóteses estratégicas coerentes, quando não houver acesso externo.
+
+## 21st.dev / Magic MCP
+
+Esta skill deve usar 21st.dev diretamente quando MCP/API estiver disponível.
+
+Não depender de outra skill para usar 21st.dev. Quando útil, a skill `ui-component-curator` pode ser invocada como caminho alternativo para análise prévia do projeto e curadoria visual.
+
+O 21st.dev é fonte prioritária para: component search, UI inspiration search, SVG icon search, Magic MCP, UI generation, component variations, landing page components, SaaS dashboard components, buttons, cards, hero sections, pricing sections, testimonials, AI chat components, text e navigation components, animated components.
+
+Quando o ambiente tiver Magic MCP disponível, usar as ferramentas MCP do 21st.dev diretamente:
+
+- `mcp__magic__21st_magic_component_inspiration`: buscar padrões e referências de seções (hero, pricing, testimonials, features);
+- `mcp__magic__21st_magic_component_builder`: gerar/instalar o componente alinhado ao stack;
+- `mcp__magic__21st_magic_component_refiner`: refinar componentes existentes;
+- `mcp__magic__logo_search`: logos de marcas (integrações, prova social, parceiros).
+
+Fluxo recomendado:
+
+1. Analisar o projeto.
+2. Identificar o nível do site.
+3. Definir quais componentes a página precisa.
+4. Pesquisar no 21st.dev por componentes compatíveis com objetivo, tom e stack.
+5. Priorizar componentes compatíveis com Next.js, React, TypeScript, Tailwind CSS, shadcn/ui e Framer Motion/Motion.
+6. Combinar resultados do 21st.dev com:
+   - React Bits para animações;
+   - Cult UI para componentes shadcn;
+   - Ali Imam para shaders e efeitos visuais;
+   - Watermelon UI para SaaS/product UI;
+   - StyleUI para templates;
+   - Design Motion Principles para regras de movimento;
+   - Taste Skill e Impeccable para qualidade visual.
+
+Se o Magic MCP ou API do 21st.dev não estiver disponível: não inventar resultados específicos, informar que o 21st.dev não está conectado, continuar usando as outras fontes disponíveis, pedir ao usuário para conectar o MCP/API se quiser busca direta no 21st.dev.
+
+## v0.app: catálogo de referência
+
+O v0 é usado **exclusivamente como catálogo de referência** (não como gerador). O MCP `v0-platform-mcp` foi removido do ecossistema: para geração de UI, use o **Magic MCP (21st.dev)**.
+
+**Fluxo de catálogo (3 passos):**
+
+1. **Buscar templates via WebFetch em `https://v0.app/community?q=<termo>`.** Funciona para queries como `liquid+glass`, `portfolio+dark`, `bento+grid`, `case+study`, `hero+webgl`.
+
+   Exemplo:
+   ```
+   url: https://v0.app/community?q=liquid+glass
+   prompt: List all templates returned. For each: title, author, URL, brief description.
+   ```
+
+2. **Apresentar 5-10 links curados** com título, autor, link absoluto e o que cada um oferece.
+
+3. **Usuário abre os templates no navegador**, copia o JSX e salva em `modelos lp/<nome>/`. A skill inspeciona a pasta local e adapta à marca.
+
+**Caveat:** WebFetch lê a lista de busca, mas não o código do template individual (renderizado por JS client-side). Por isso o passo 3 é manual. Não tente extrair código de template via WebFetch diretamente.
+
+**Alternativa opt-in:** usar **agent-browser** pra abrir o template no browser real e extrair código/screenshot. Mais tokens: só vale quando o template é crítico e o usuário não quer copiar manual. **Não usar Playwright.**
+
+**Overlap com modelos locais:** muitos templates populares do v0 já podem estar na pasta `modelos lp/` do usuário. Inspecionar a pasta local primeiro antes de chamar WebFetch.
+
+## Authorized Component / Code Inspection Sources
+
+Estas fontes podem ser clonadas temporariamente, com permissão do usuário, para inspecionar componentes, exemplos ou registries.
+
+### React Bits
+
+```text
+https://github.com/DavidHDev/react-bits.git
+```
+
+Usar para: animações React, text effects, animated backgrounds, scroll effects, hover effects, cards animados, microinterações, loaders, hero animations, partículas, efeitos de cursor, detalhes visuais interativos.
+
+Priorizar componentes open source. Não recomendar nem listar componentes React Bits Pro como dependência obrigatória.
+
+### Cult UI
+
+Usar docs, GitHub ou registry público quando disponível:
+
+```text
+https://www.cult-ui.com/docs
+https://github.com/nolly-studio/cult-ui
+```
+
+Usar para: componentes shadcn, hero sections, botões sofisticados, cards animados, marketing sections, componentes com visual premium, componentes para landing pages.
+
+Usar apenas recursos públicos/open source, salvo confirmação de acesso pago.
+
+### Ali Imam
+
+```text
+https://github.com/aliimam-in/aliimam.git
+```
+
+Usar para: shaders, liquid wave, pixel grid, ripple shader, border glow, bento layouts, typewriter effects, canvas-based effects, efeitos visuais experimentais.
+
+Se a estrutura do repositório estiver incerta: inspecionar docs primeiro, pedir confirmação antes de clonar, não assumir nomes de componentes sem verificar.
+
+### Watermelon UI
+
+```text
+https://github.com/WatermelonCorp/watermellon-registry.git
+```
+
+Usar para: SaaS components, dashboards, product UI, cards, app sections, UI blocks, interfaces de produto, layouts funcionais, componentes de startup.
+
+### StyleUI
+
+```text
+https://github.com/heyfabrika/styleui.git
+```
+
+Usar para: templates, landing page layouts, páginas prontas, seções instaláveis, fundamentos rápidos de layout, páginas base.
+
+### Skiper UI
+
+Skiper UI **não deve ser clonado**.
+
+Usar o comando público:
+
+```bash
+npx shadcn add @skiper-ui/skiper40
+```
+
+Usar somente componentes públicos/gratuitos, a menos que o usuário confirme acesso premium.
+
+Usar para: uncommon shadcn components, efeitos visuais diferenciados, seções premium, animações avançadas, componentes menos genéricos.
+
+Evitar: depender de componentes premium sem autorização; assumir acesso pago.
+
+## Authorized Reference Inspection Sources
+
+Estas fontes podem ser inspecionadas ou consultadas para princípios, critérios de qualidade, motion e taste, mas **não devem ser tratadas como dependências de projeto**.
+
+### Impeccable
+
+```text
+https://github.com/pbakaus/impeccable.git
+```
+
+Usar para: visual taste, spacing, hierarchy, composição visual, design fluency, evitar UI amadora, melhorar refinamento visual.
+
+Impeccable não é fonte de componentes. É fonte de julgamento visual.
+
+### Taste Skill
+
+```text
+https://github.com/Leonxlnx/taste-skill.git
+```
+
+Usar como camada anti-generic frontend.
+
+Aplicar para: evitar UI genérica de IA, melhorar hierarquia, melhorar spacing, melhorar composição, deixar a interface mais premium, corrigir visual "template", revisar se o design parece feito por especialista.
+
+Sempre aplicar quando a landing parecer genérica, o projeto for avançado ou high-end, o usuário pedir qualidade premium, o site precisar parecer caro.
+
+### Design Motion Principles
+
+```text
+https://github.com/kylezantos/design-motion-principles.git
+```
+
+Usar para: easing, timing, scroll motion, reveal logic, microinteraction rules, motion hierarchy, duração de animações, entrada e saída de elementos, evitar animação caótica, consistência de movimento.
+
+### MotionSites
+
+```text
+https://github.com/aayushsoam/motionsites.ai.git
+```
+
+Classificação: referência visual, referência de motion, biblioteca de prompts/ideias, fonte de inspiração para hero, scroll storytelling e animações.
+
+**Não tratar MotionSites como fonte principal de componentes instaláveis.** Se houver repositório disponível, pode ser inspecionado apenas para pesquisa de referências e padrões, não como dependência do projeto.
+
+Usar para: motion references, animated landing ideas, hero prompts, scroll storytelling, cinematic web sections, exemplos de movimento, direção de animação.
+
+### Vibe Code Components
+
+```text
+https://vibecodecomponents.com/
+```
+
+Classificação: referência visual, fonte de prompts, inspiração de componentes, vibe coding reference.
+
+**Não tratar como fonte garantida de código instalável**, a menos que o conteúdo acessível confirme isso.
+
+Usar para: vibe coding references, prompt ideas, component inspiration, UI patterns, visual exploration, ideias de seções, direção visual rápida, componentes modernos.
+
+> **Regra importante:** MotionSites e Vibe Code Components podem aparecer em `Reference Sources` e `Visual Inspiration Sources`, mas não devem ser tratadas como fontes primárias de implementação igual React Bits, Cult UI, Watermelon ou StyleUI.
+
+## Visual Inspiration Sources
+
+Estas são fontes visuais para a skill usar quando precisar de direção visual, inspiração, estilo, animação, composição e UX. Não devem ser tratadas como fonte garantida de código.
+
+### 1. Landing Love
+
+URL: `https://www.landing.love/`
+
+Melhor para pesquisar: landing pages animadas, scroll effects, WebGL, GSAP, Framer, Webflow, páginas com vídeo de navegação, storytelling visual, motion em páginas reais.
+
+Quando usar: projeto precisa de inspiração de landing page animada, usuário quer algo moderno/dinâmico, skill precisa entender ritmo de scroll e transições.
+
+### 2. Godly
+
+URL: `https://godly.website/`
+
+Melhor para pesquisar: sites premium, composição visual, tipografia, direção de arte, layout editorial, estética high-end, referências de marcas digitais.
+
+Quando usar: projeto precisa parecer sofisticado, direção visual está fraca, site precisa parecer caro e não genérico.
+
+### 3. Design Spells
+
+URL: `https://www.designspells.com/`
+
+Melhor para pesquisar: microinterações, detalhes de UI, easter eggs, pequenas animações, momentos de encantamento, interação fina.
+
+Quando usar: site já estruturado mas precisa de detalhes memoráveis, projeto precisa de acabamento visual, experiência precisa parecer mais viva.
+
+### 4. Spline
+
+URL: `https://spline.design/`
+
+Melhor para pesquisar: cenas 3D, hero 3D, objetos interativos, product visuals, embeds 3D, experiências espaciais.
+
+Quando usar: projeto 3D High-End, modo Signature 3D, marca tech/futurista, produto que ganha valor com visual 3D.
+
+Trabalhar dentro do plano gratuito do Spline. Respeitar limites de exportação, watermark e número de cenas. Não pressupor licença paga.
+
+### 5. Unicorn Studio
+
+URL: `https://www.unicorn.studio/`
+
+Melhor para pesquisar: WebGL backgrounds, motion assets, efeitos no-code, shaders visuais, fundos interativos, efeitos de partículas.
+
+Quando usar: site precisa de impacto visual, projeto quer WebGL sem implementar tudo manualmente, skill precisa sugerir background animado ou efeito atmosférico.
+
+Trabalhar dentro do plano gratuito. Respeitar limites e marca d'água. Não pressupor licença paga.
+
+### 6. Mobbin
+
+URL: `https://mobbin.com/`
+
+Melhor para pesquisar: UX real, fluxos de apps, onboarding, pricing pages, dashboards, mobile UI, padrões de produto.
+
+Regra: Mobbin pode exigir login/pagamento. Usar apenas se houver acesso, previews públicos ou referências enviadas pelo usuário. Não depender de Mobbin no fluxo principal.
+
+### 7. ScreensDesign / DesignVault
+
+URLs: `https://screensdesign.com/` · `https://designvault.io/`
+
+Melhor para pesquisar: onboarding mobile, paywalls, app screens, subscription flows, telas com foco em conversão, UX de apps.
+
+Regra: pode exigir plano/pagamento para uso completo. Usar apenas quando houver acesso ou como referência visual pública.
+
+### Fontes que o usuário pode fornecer manualmente
+
+- **Prints, screenshots, vídeos, Figma, Behance, Dribbble, sites concorrentes**: tratar como fonte de prioridade alta. A referência do usuário vale mais que catálogo genérico.
+- **Componentes ou trechos de código que o usuário cole no chat**: tratar como base autoritativa para estilo, padrão e direção.
+- **Bibliotecas premium que o usuário declarar ter acesso** (React Bits Pro, Cult UI Pro, Skiper UI premium, Mobbin, ScreensDesign Pro, etc.): a skill **não pressupõe esse acesso**, mas se o usuário confirmar, pode usar.
+
+### Visual Inspiration Rules
+
+Usar fontes visuais apenas como inspiração, não como fonte garantida de código.
+
+Usar para: direção visual, padrões de layout, ritmo de seções, microinterações, animações, composição, atmosfera, inspiração de scroll, linguagem visual, UX real, onboarding, paywalls, dashboards, pricing pages.
+
+Não prometer código pronto quando a fonte for apenas visual. Não copiar visualmente um site inteiro de referência. Usar referências para criar uma solução original, adaptada ao projeto.
+
+## Clone Policy
+
+**Não clonar nada automaticamente.**
+
+Se precisar clonar uma fonte de componentes ou referência, perguntar antes.
+
+Ordem preferida:
+
+1. usar source map conhecido;
+2. usar docs públicas;
+3. usar web/search se disponível;
+4. usar registry URL se disponível;
+5. pedir permissão antes de clonar;
+6. clonar apenas em pasta temporária ou claramente nomeada.
+
+Clonar apenas em pasta temporária, como:
+
+```text
+.design-sources-temp/
+```
+
+Nunca clonar diretamente dentro da estrutura principal do app.
+
+A skill pode clonar temporariamente apenas repositórios das listas `Authorized Component / Code Inspection Sources` e `Authorized Reference Inspection Sources`.
+
+Usar repositórios clonados somente para: pesquisa, inspeção, descoberta de componentes, exemplos, orientação de implementação.
+
+Não manter repositórios clonados como dependência do projeto sem confirmação explícita.
+
+## Paid Source Policy
+
+Não depender de fontes pagas no fluxo principal.
+
+Remover dependência obrigatória de:
+
+- Mobbin pago;
+- ScreensDesign pago;
+- React Bits Pro;
+- Cult UI Pro;
+- Skiper UI premium;
+- Spline pago;
+- Unicorn Studio pago;
+- v0 pago como obrigação.
+
+Usar ferramentas pagas apenas se:
+
+- o usuário confirmar acesso;
+- a credencial estiver disponível;
+- o projeto explicitamente exigir;
+- a fonte for opcional.
+
+Sempre preferir: open source, registry público, GitHub, docs públicas, screenshots do usuário, referências fornecidas.
+
+Não burlar paywall, login, licenças, limites de plano ou proteções de sites. Se houver dúvida sobre licença, avisar e sugerir alternativa open source.
+

package/src/skills-lib/premium-landing-ui-researcher/references/core-goal.md

@@ -0,0 +1,62 @@
+## Core Goal
+
+Esta skill atua como um estrategista autônomo de landing pages premium, interfaces SaaS e experiências visuais avançadas.
+
+Ela deve conseguir analisar um projeto e entregar uma landing page, dashboard ou experiência digital de alto nível sem o usuário precisar enviar referências manuais toda vez.
+
+A skill deve:
+
+- analisar o negócio, produto, serviço ou oferta;
+- entender público-alvo, objetivo e nível de sofisticação necessário;
+- fazer poucas perguntas quando faltar contexto;
+- escolher o nível visual correto do projeto;
+- pesquisar componentes, animações e referências nas fontes configuradas;
+- usar 21st.dev diretamente via MCP/API quando disponível;
+- usar o catálogo público do v0.app (WebFetch) para descoberta de templates de referência;
+- usar repositórios autorizados como fonte de pesquisa;
+- clonar temporariamente repositórios autorizados apenas quando necessário e com permissão;
+- escolher scroll effects, 3D hero, WebGL, shaders, microinterações e componentes com base no tom da marca;
+- escrever copy completa, estratégica e orientada à conversão;
+- criar estrutura completa de landing page;
+- sugerir dashboard SaaS quando fizer sentido;
+- entregar plano de implementação;
+- aplicar princípios de gosto visual, motion, hierarquia, UX e conversão;
+- evitar resultados genéricos, artificiais ou com aparência de template barato.
+
+Use esta skill como um especialista sênior em design, front-end, copywriting, posicionamento e conversão.
+
+> Importante: nunca colocar chaves reais dentro da skill. Usar somente variáveis de ambiente para qualquer credencial.
+
+### Regra de autonomia
+
+A skill não depende do usuário para enviar referências toda vez.
+
+Se nenhuma referência for fornecida, a skill infere uma direção visual de alta qualidade usando: tipo de negócio, público-alvo, oferta, objetivo da página, tom de marca, ticket percebido, nível de complexidade, objetivo de conversão, necessidade ou não de 3D, necessidade ou não de dashboard SaaS, stack disponível e fontes internas configuradas na skill.
+
+A skill só deve pedir referências quando:
+
+- o gosto visual for altamente subjetivo;
+- o usuário pedir um estilo muito específico;
+- houver necessidade de copiar uma estética de marca existente;
+- o projeto exigir fidelidade visual a concorrentes ou benchmarks.
+
+## Project Intelligence Mode
+
+Antes de pesquisar componentes, animações, referências visuais ou gerar qualquer landing page, analisar o contexto do projeto.
+
+Se o usuário já forneceu informações suficientes (negócio, público, objetivo, nível visual, referências), seguir direto.
+
+Se faltarem dados importantes, fazer **no máximo 5 perguntas estratégicas**:
+
+1. Qual é o negócio, produto, serviço ou oferta?
+2. Quem é o público-alvo?
+3. Qual é o objetivo principal da página? (vender, captar lead, agendar reunião, WhatsApp, apresentar serviço, etc.)
+4. Qual nível visual o projeto deve ter: básico, intermediário, avançado ou 3D high-end?
+5. Existe alguma referência visual, concorrente, print, vídeo ou direção de marca?
+
+Se o usuário não responder tudo, continuar com hipóteses estratégicas coerentes. Não bloquear o trabalho por dados ausentes.
+
+Regra mestra: **perguntar, inferir, executar.** Não fazer perguntas demais. Não pedir reconfirmação de coisas já ditas. Não devolver brief para o usuário preencher.
+
+Quando o usuário pedir algo como "crie meu site", "melhore minha landing", "faça algo premium", "quero algo 3D", "quero algo outro nível", usar este modo automaticamente.
+

package/src/skills-lib/premium-landing-ui-researcher/references/dashboard-and-portfolio-modes.md

@@ -0,0 +1,92 @@
+## SaaS Dashboard Mode
+
+Quando o projeto for SaaS, app, plataforma, AI tool, CRM, analytics product, produto com login, internal tool ou productized service, considerar se o projeto também precisa de dashboard.
+
+Se fizer sentido, criar ou recomendar um dashboard SaaS completo junto da landing page.
+
+O dashboard pode incluir:
+
+- sidebar navigation;
+- top bar;
+- KPI cards;
+- charts;
+- tables;
+- onboarding state;
+- empty states;
+- loading states;
+- skeleton states;
+- error states;
+- notifications;
+- settings page;
+- billing area;
+- subscription area;
+- user/profile area;
+- upgrade prompts;
+- usage metrics;
+- responsive layout;
+- mobile layout;
+- command menu;
+- activity feed.
+
+A skill decide se o dashboard é necessário com base no tipo de projeto, na presença de login, no modelo de negócio e na pergunta direta ao usuário quando houver dúvida.
+
+Quando o usuário pedir landing + produto, entregar:
+
+1. landing page estratégica;
+2. dashboard SaaS sugerido;
+3. arquitetura visual compartilhada entre landing e dashboard;
+4. componentes principais reutilizados;
+5. estados de interface (empty, loading, error, success);
+6. plano de implementação faseado.
+
+O dashboard deve seguir a mesma identidade visual da landing page (cores, tipografia, espaçamento, radius, tom). Não tratar dashboard como um produto visual separado da landing.
+
+## Portfolio / Authority Site Mode
+
+Quando o objetivo do site for autoridade, portfolio, marca pessoal, estúdio, agência premium ou lead passivo, **não tratar como sales page agressiva**.
+
+Ativar este modo quando:
+
+- o cliente vende serviço consultivo premium ou high-ticket;
+- o objetivo principal é mostrar autoridade e portfolio (não captação direta);
+- o público é maduro (founders, C-level, peers, mercado premium);
+- a marca é autoral, estúdio, boutique ou agência selecionada;
+- o funnel é por inbound qualificado, indicação ou conversa privada;
+- pressão de conversão queimaria o posicionamento.
+
+Priorizar:
+
+- manifesto;
+- selected work;
+- case deep-dive;
+- capabilities;
+- recognition;
+- conversa discreta;
+- CTA editorial;
+- prova por execução visual;
+- copy sofisticada e sem urgência falsa.
+
+Evitar:
+
+- FAQ tradicional se parecer low-end;
+- pricing público se o serviço for premium/custom;
+- excesso de depoimentos genéricos;
+- urgência falsa;
+- copy agressiva de funil;
+- popups, exit intents e sticky CTAs barulhentos;
+- promessas mensuráveis sem prova real ("3x mais vendas em 30 dias");
+- elementos de e-commerce em site de serviço autoral.
+
+Quando este modo estiver ativo, ajustar:
+
+- **CTA principal**: editorial e discreto (`Start a conversation`, `hello@marca.com`, `Agendar uma call de 30 min`), não popup, não sticky agressivo;
+- **Hero**: statement editorial, não promessa de resultado bombástica;
+- **Prova social**: logo grid monocromático + 1-2 quotes editoriais longas, não carrossel de testimonials;
+- **Estrutura**: substituir FAQ por case deep-dive; substituir pricing por capabilities + processo;
+- **Microcopy**: tom adulto, sem exclamação, sem caps lock estratégico, sem emoji decorativo;
+- **Ritmo**: mais espaço negativo, mais respiro entre seções, menos seções no total.
+
+Este modo é compatível com 3D High-End e Signature 3D Experience. A combinação Portfolio/Authority + Signature 3D é ideal para agências premium, estúdios de design/dev e marcas pessoais de especialistas que querem o site funcionar como prova viva de capacidade.
+
+Este modo **não** é compatível com External CTA / WhatsApp Mode agressivo. Se o cliente quiser WhatsApp como CTA, manter o botão discreto no nav e no footer, sem sticky mobile e sem microcopy de urgência.
+

package/src/skills-lib/premium-landing-ui-researcher/references/handoffs.md

@@ -0,0 +1,55 @@
+## Handoff para motion-3d-director
+
+Quando o nível for **3D High-End** ou **Signature 3D Experience**, a landing strategist (esta skill) deve enviar para o `motion-3d-director`:
+
+- brief visual;
+- feeling;
+- hero object;
+- three-second memory;
+- color logic;
+- typography logic;
+- spatial logic;
+- objetivo do site;
+- público;
+- nível escolhido (3D High-End ou Signature 3D);
+- se existe logo;
+- se existe imagem;
+- se existe mockup;
+- se existe produto;
+- se precisa ser interativo;
+- restrições de performance;
+- caminho esperado (3D real, image-to-video, hybrid ou motion 2D).
+
+O `motion-3d-director` deve retornar:
+
+- diagnóstico de motion;
+- caminho recomendado;
+- assets necessários;
+- prompt de imagem;
+- prompt de vídeo;
+- plano de implementação;
+- fallback mobile;
+- performance notes;
+- o que evitar.
+
+Os termos `feeling`, `hero object`, `three-second memory`, `color logic`, `typography logic` e `spatial logic` vêm do brief produzido pela skill `decision-maker` (seis decisões + três lógicas). Se o usuário ainda não tem brief, sugerir rodar `decision-maker` primeiro: handoffs para 3D sem brief produzem genérico.
+
+---
+
+## Handoff para implementation-planner
+
+A `implementation-planner` deve receber:
+
+- nível de motion (1–5);
+- motion budget correspondente;
+- componentes a usar;
+- animações a implementar;
+- plano 3D/video (vindo do motion-3d-director, se aplicável);
+- assets;
+- stack (Next.js, Tailwind, shadcn/ui, Framer Motion, GSAP, R3F, etc.);
+- performance constraints (Core Web Vitals, mobile fallback, reduced-motion).
+
+Regra crítica: **não implementar R3F/Three.js se o `motion-3d-director` decidir image-to-video ou hybrid sem 3D real.** A escolha de caminho do diretor de motion é decisiva: o planner executa, não re-decide.
+
+---
+