wizz-method 1.18.0 → 1.18.1

package/package.json

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

package/skills-registry.yaml

@@ -64,7 +64,8 @@
 version: 1
 
 # ─────────────────────────────────────────────────────────────────────────────
-# ÁREAS — cada uma tem um agente dono (executor) e as skills que ele puxa.
+# ÁREAS — `agent` identifica uma SKILL de persona, invocada via Skill.
+# Não usar esse valor como subagent_type. Subagentes nativos são wizz-exec-*.
 # ─────────────────────────────────────────────────────────────────────────────
 areas:
   designer:
@@ -132,22 +133,7 @@ areas:
       - 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."
-    mcps:
-      - id: magic
-        when: "Gerar/refinar componentes prontos via 21st.dev (UI builder, inspiration, refiner)."
-        server:
-          command: npx
-          # Pin de supply chain (2026-08-23): versão fixa; atualizar conscientemente.
-          args: ["-y", "@21st-dev/magic@0.2.2"]
-          env:
-            API_KEY: "${MAGIC_API_KEY}"
     clis:
-      - id: 21st-cli
-        when: "Fonte PAGA complementar (catálogos gratuitos como React Bits/Cult UI/Componentry vêm primeiro; gate de aprovação do usuário). Buscar, inspecionar, instalar e publicar componentes no 21st.dev via terminal (search/get/add/publish, registry do time @wizzdigitalagency). Complementa o Magic MCP (geração assistida); é o caminho de catálogo/registry e o fallback declarado quando o MCP está offline. O install traz também as skills oficiais 21st-cli-use, 21st-registry e 21st-design-sync. Login interativo: `21st login` (em CI usar env API_KEY_21ST)."
-        rel:
-          pairs_with: [magic]
-        check: "command -v 21st"
-        install: "npm i -g @21st-dev/cli && npx @21st-dev/cli install-skill"
       - 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."
         not_when: "Montagem com áudio/SFX/legenda sincronizada (posicionador de áudio falhou em produção, ~2,76s de drift; CSS vaza entre telas)."

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

@@ -4,10 +4,11 @@ Contrato mínimo que todo orquestrador ou spawn de subagente usa ao delegar
 trabalho: wizz-router, wizz-maestro, wizz-party-mode (subagent/agent-team)
 e swarm-orchestrator. Objetivo: cortar a dupla consulta ao cerebro (cerebro
 pago 2x na mesma cadeia), travar o loop router-maestro-router, e passar só
-a seção da skill que importa (progressive disclosure), não a skill inteira.
+o entrypoint da skill e apenas as referências necessárias (progressive disclosure), não o pacote inteiro.
 
 ## Campos do brief
 
+- skill de área: nome canônico da persona a invocar via `Skill` (ex.: `wizz-growth`). Não é `subagent_type`: para isolar a tarefa, escolha um executor nativo disponível (`wizz-exec-*`) e instrua-o a carregar essa skill antes de trabalhar. A ausência de um executor não impede invocar a skill na sessão atual.
 - origem: quem está delegando (ex: wizz-router, wizz-maestro). Regra
   anti-loop: nunca invoque quem já está na cadeia de origem. Exemplo
   proibido: router delega pro maestro, maestro devolve pro router.
@@ -17,9 +18,10 @@ a seção da skill que importa (progressive disclosure), não a skill inteira.
   novo, usa o resumo recebido.
 - decisões já tomadas na cadeia: lista curta do que já foi decidido antes
   deste handoff (ex: paleta aprovada, escopo definido).
-- seção relevante da skill: aponte o arquivo ou seção específica a
-  carregar, não a skill inteira (ex: paid-ads/references/budget.md). Quem
-  recebe carrega só isso, não o pacote completo da skill.
+- seção relevante da skill: indique o assunto e as referências necessárias.
+  Quem recebe carrega primeiro o SKILL.md completo via invocação da skill;
+  depois lê apenas as referências exigidas pela tarefa. Skills carregadas
+  pelo lead não são herdadas automaticamente por um subagente.
 - model_hint (opcional): degrau da escada, não modelo cru. Valores:
   `haiku | sonnet | opus | review`. Quem recebe despacha `wizz-exec-<hint>`
   (nativo em Claude Code, Codex, OpenCode e Gemini CLI). Escalada: no

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

@@ -34,5 +34,7 @@ Para cada tarefa, **entre pela porta certa via a ferramenta `Skill`** e traga o
 
 Sempre **mostre o visual/plano antes do código**. Construção de código é com o **wizz-agent-dev**; para ajuste pontual, indique **wizz-quick-dev**.
 
+**Gate de pesquisa:** para componente/efeito não trivial, cobre da porta de construção o registro de buscas, demos e código/registry exatos, revisão/data, licença, dependências, avaliação visual e motivo da escolha. A saída de `ui-ux-pro-max` é uma busca local de diretrizes, não mineração de componentes na web. Antes do handoff para dev, confirme as evidências ou declare as limitações e a justificativa da implementação própria. Fontes opcionais indisponíveis não bloqueiam a pesquisa em outras fontes públicas.
+
 ## Encerramento
 Termine no formato Wizz: `✅ O que fiz` (frases simples) / `➡️ Próximo passo` (geralmente wizz-agent-dev ou wizz-quick-dev pra construir) / `🎯 Comando`.

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

@@ -8,6 +8,8 @@ description: Wizz Method Growth and Conversion Agent. Use when you need marketin
 ## Visão geral
 Você é o Growth do Wizz. Traz ideias acionáveis de marketing e conversão, planeja lançamentos, ajusta preço e ataca churn. Nada de teoria solta. Roteia para as skills globais via a ferramenta `Skill`.
 
+**Invocação:** esta persona é uma skill (`Skill(skill="wizz-growth", args="<brief>")`), não um `subagent_type`. Uma passada de CRO contra um shard pode rodar nesta sessão ou em um executor nativo disponível (`wizz-exec-*`) que carregue esta skill e receba o shard no brief.
+
 ## Na ativação
 1. **Resolver bloco:** rode `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key agent`. Se falhar, mescle base → time → pessoal (`{skill-root}/customize.toml`, `{project-root}/_wizz/custom/{skill-name}.toml`, `.user.toml`).
 2. Execute `{agent.activation_steps_prepend}`.

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

@@ -75,7 +75,7 @@ O Diretor (`wizz-router`) já fez a triagem e te entregou porque é complexo. Se
 2. **Enriquecimento = o `skills-registry.yaml`**. Para a área escolhida, ele diz O QUE o agente puxa:
    - `areas:` — `agent` (deve casar com o do menu) e `skills:` (cada uma com `id` + `when` curto). Instrua o agente a invocar a(s) skill(s) global(is) cujo `when` casa com o pedido.
    - `utility:` — skills cross-cutting (find-skills, enhance-prompt, wizz-router). Ofereça quando couber.
-   - `mcps:` (por área) e `mcp_utility:` (cross-cutting) — MCP servers que a área usa pra AGIR de verdade (ex: designer→magic, architect→supabase, ads→meta-ads, analyst→exa, util→context7; qa NÃO usa MCP de browser — é agent-browser via CLI). Se o pedido precisa de acesso real à ferramenta e o MCP não está ativo (`claude mcp list`), proponha `claude mcp add <id> -- <command>` usando o bloco `server` do registry (secrets via env/placeholder).
+   - `mcps:` (por área) e `mcp_utility:` (cross-cutting) — MCP servers que a área usa pra AGIR de verdade (ex: architect→supabase, ads→meta-ads, analyst→exa, util→context7; qa NÃO usa MCP de browser — é agent-browser via CLI). Se o pedido precisa de acesso real à ferramenta e o MCP não está ativo (`claude mcp list`), proponha `claude mcp add <id> -- <command>` usando o bloco `server` do registry (secrets via env/placeholder).
    - `clis:` (por área) e `cli_utility:` (cross-cutting) — ferramentas de linha de comando que o agente chama direto (não são skill nem MCP): ex. qa→agent-browser; designer→hyperframes/claude-video/buttercut/voicebox (vídeo); ads→arcads; growth→scrapling; seo→distribb. Quando o `when:` casar com o pedido, ofereça a tool: rode o `check:` pra ver se já está instalada; se não, mostre o `install:` (opt-in, nunca auto-rode sem confirmar). Respeite o campo `platform:` — se presente e não casar com o OS/arch atual, NÃO ofereça (ex.: `buttercut` é `darwin-arm64`, só Apple Silicon). Clone-and-run (buttercut/voicebox/arcads) instala no projeto; avise sobre deps pesadas.
    - `squads:` — painéis consultivos (rodam via `wizz-party-mode`). Quando o pedido pedir validação/estratégia de um `domain`, rode o squad ANTES do agente em `advises` executar.
 
@@ -102,7 +102,11 @@ Regra de handoff:
 
 ### Handoff ao delegar
 
-Ao invocar o agente de área, declare o brief no formato do [protocolo de handoff compartilhado](../../../../core-skills/_shared/handoff-protocol.md): `origem` (você, para o anti-loop — o agente nunca devolve pra você o mesmo pedido), `cérebro já consultado` (o resumo de até 3 linhas que você já puxou no Passo 2, cortando a consulta duplicada do agente), decisões já tomadas na cadeia, a seção relevante da skill (não a skill inteira) e `model_hint` opcional. O agente de área que receber esse resumo pula o próprio passo de `/cerebro ver`.
+**Contrato de invocação:** `areas.<area>.agent` e os destinos do menu são nomes de **skills de persona**, não tipos nativos de subagente. Na sessão atual, invoque `Skill(skill="wizz-growth", args="<brief de CRO>")` (ou a skill da área escolhida). Nunca passe `wizz-growth`, `wizz-designer`, `wizz-qa` ou `wizz-maestro` como `subagent_type` só porque o registry os chama de agentes.
+
+Para trabalho isolado/paralelo, selecione um `wizz-exec-*` que esteja na lista de agentes disponíveis e passe no brief a skill de área a carregar, o shard e o escopo. O executor deve carregar a skill de entrada completa antes das referências relevantes; não herda as skills já carregadas pelo maestro. Se não houver executor adequado disponível, execute a skill na sessão atual. Se a skill também faltar, reporte a instalação ausente, sem inventar um tipo de agente nem repetir a chamada que falhou.
+
+Ao invocar o agente de área, declare o brief no formato do [protocolo de handoff compartilhado](../../../../core-skills/_shared/handoff-protocol.md): `origem` (você, para o anti-loop — o agente nunca devolve pra você o mesmo pedido), `cérebro já consultado` (o resumo de até 3 linhas que você já puxou no Passo 2, cortando a consulta duplicada do agente), decisões já tomadas na cadeia, a skill de entrada e as referências relevantes (sem carregar referências alheias à tarefa) e `model_hint` opcional. O agente de área que receber esse resumo pula o próprio passo de `/cerebro ver`.
 
 **Não tem agente/skill/MCP para o pedido:** diga isso e ofereça `find-skills`. Ele cobre os dois caminhos: skill faltante → `npx skills find/add`; capacidade de ferramenta faltante → `claude mcp add` (usando o `server` do registry). Classifique antes: precisa SABER COMO = skill; precisa AGIR num sistema = MCP.
 

package/src/skills-lib/find-skills/SKILL.md

@@ -164,7 +164,6 @@ claude mcp add <id> [-e VAR=valor ...] -- <command> [args...]
 # necessário):
 claude mcp add context7 -- npx -y @upstash/context7-mcp@3.2.2
 claude mcp add exa -e EXA_API_KEY=$EXA_API_KEY -- npx -y exa-mcp-server@3.2.1
-claude mcp add magic -e API_KEY=$MAGIC_API_KEY -- npx -y @21st-dev/magic@0.1.0
 claude mcp add supabase -e SUPABASE_ACCESS_TOKEN=$SUPABASE_ACCESS_TOKEN -- npx -y @supabase/mcp-server-supabase@0.8.2 --read-only
 ```
 Versões acima são as pinadas hoje em `skills-registry.yaml` — confira lá antes de copiar, pode ter mudado. Não sugira o MCP do Playwright: browser é sempre via CLI `agent-browser` neste framework, nunca Playwright.

package/src/skills-lib/impeccable/SKILL.md

@@ -1,30 +1,28 @@
 ---
 name: impeccable
-description: "Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks."
-argument-hint: "[{{command_hint}}] [target]"
+description: "Use when the user wants to review, audit, polish, redesign or improve a frontend interface. Covers hierarchy, accessibility, responsive layout, typography, color, motion, UX copy and component consistency. Wizz's self-contained adaptation runs on project evidence and bundled references."
+argument-hint: "[audit|critique|polish|shape|document|adapt|harden] [target]"
 user-invocable: true
-allowed-tools:
-  - Bash(npx impeccable *)
 license: Apache 2.0
 ---
 
-Designs and iterates production-grade frontend interfaces. Real working code, committed design choices, exceptional craft.
+# Impeccable — Wizz adaptation
 
-## Setup (first step, always run before anything else)
+Design and review working interfaces using project evidence. This bundle contains instructions and design rules; it does not ship the upstream CLI, detector, context scripts or native engine. Do not invent commands or claim those checks ran.
 
-You MUST do these steps before proceeding:
+## Setup
 
-1. Run `node {{scripts_path}}/context.mjs` once per session. If you've already seen its output in this conversation, do not re-run it. The script either prints the project's PRODUCT.md (and DESIGN.md when present) as a markdown block, or tells you it's missing. Follow whatever it prints. **If it reports `NO_PRODUCT_MD`, stop and follow `reference/init.md` before doing anything else.** If the output ends with an `UPDATE_AVAILABLE` directive, follow it (ask the user once about updating, then continue). It never blocks the current task.
-2. If the user invoked a sub-command (`craft`, `shape`, `audit`, `polish`, ...), you MUST read `reference/<command>.md` next. Non-optional. The reference defines the command's flow; without it you will skip steps the user expects.
-3. Familiarize yourself with any existing design system, conventions, and components in the code. Read at least one project file (CSS / tokens / theme / a representative component or page). **Required even when you've loaded a sub-command reference in step 2.** Don't reinvent the wheel; use what's there when it works, branch out when the UX wins.
-4. Read the matching register reference. **This is non-optional; skipping it produces generic output.** If the project is marketing, a landing page, a campaign, long-form content, or a portfolio (design IS the product), read `reference/brand.md`. If it is app UI, admin, a dashboard, or a tool (design SERVES the product), read `reference/product.md`. Pick by first match: (1) task cue ("landing page" vs "dashboard"); (2) surface in focus (the page, file, or route being worked on); (3) `register` field in PRODUCT.md.
-5. **If the project is brand-new (no existing CSS tokens / theme / committed brand colors found in step 3)**, run `node {{scripts_path}}/palette.mjs` to receive a brand seed color and composition guidance. This is the anchor for your primary brand color. Compose the rest of the palette (bg, surface, ink, accent, muted) around it per the script's instructions. Use OKLCH throughout. **Skip this step only if step 3 found committed brand colors in existing tokens; in that case identity-preservation wins.**
+1. Read the user's brief, existing PRODUCT.md/DESIGN.md when present, and at least one relevant UI source file (tokens, theme, component or page). Missing documents alone do not make an existing project greenfield.
+2. Preserve the established identity during refinement. For a requested redesign, choose a new direction while preserving product facts, functionality and user constraints. Explicit user choices take precedence over generic anti-pattern warnings.
+3. Choose the surface mode: **Persuade** (landing/marketing), **Operate** (app/dashboard), **Read** (docs/articles) or **Experience** (portfolio/gallery). A product can have surfaces in different modes.
+4. Map the requested action using [routing-rules](references/routing-rules.md). Read [command-workflows](references/command-workflows.md) for the relevant workflow and [design-rules](references/design-rules.md) before reviewing or changing UI.
+5. For new nontrivial components, invoke `skill:premium-landing-ui-researcher` or `skill:ui-component-curator` to obtain inspected sources. Do not replace source research with generic taste recommendations.
 
-## Design guidance
+## Verification
 
-Produce ready-to-ship, production-grade code, not prototypes or starting points. Take no shortcuts unless the user asks for them (when in doubt, ask). Don't stop until arriving at a complete implementation (beautiful, responsive, fast, precise, bug-free, on brand). You take attention to detail seriously: every page, section or component crafted is battle tested using the tools available to you (browser screenshotting, computer use, etc). {{model}} is capable of extraordinary work. Don't hold back.
+Build the authorized change, inspect the affected desktop/mobile states in one batch, fix the observed issues together and confirm once more. Additional passes need a specific unresolved defect. Verify keyboard/focus, responsive overflow, reduced-motion and relevant project checks. If the app cannot run, use current screenshot fixtures and code, and state the limitation.
 
-**Before writing or reviewing any UI code, load `references/design-rules.md`** — the ruleset every craft/polish/audit/critique pass is checked against. Skipping it is the most common way this skill produces generic or AI-tell-heavy output.
+Report findings with file/route, observed evidence, impact and proposed correction. Distinguish observed defects from taste preferences. Never claim an automatic detector, browser test or performance measurement without running it.
 
 ## Commands
 
@@ -54,17 +52,14 @@ Produce ready-to-ship, production-grade code, not prototypes or starting points.
 | `optimize [target]` | Fix | Diagnose and fix UI performance |
 | `live` | Iterate | Visual variant mode: pick elements in the browser, generate alternatives |
 
-Each command's flow lives at `reference/<command>.md` (e.g. `reference/craft.md`, `reference/live.md` — vendored, per Setup step 2). Plus three management commands: `pin <command>`, `unpin <command>`, and `hooks <on|off|status|...>` — see `references/pin-unpin-and-hooks.md`.
 
-**If the first word matches a command** (table above OR `pin` / `unpin` / `hooks`): load its reference file and follow its instructions. Everything after the command name is the target. **If no argument was given, or the intent doesn't obviously name a command**, load `references/routing-rules.md` for the full routing logic (context-aware menu, signal-based recommendations, intent mapping, fallback general invocation).
+Command names above select the bundled [command-workflows](references/command-workflows.md); they are not shell commands. Management requests (`pin`, `unpin`, `hooks`) use [pin-unpin-and-hooks](references/pin-unpin-and-hooks.md). `teach` aliases `init`.
 
-`teach` is a deprecated alias for `init`: if the user types it, load [reference/init.md](reference/init.md) and proceed as if they ran `init`.
+## References
 
-## Reference map — load each file when needed
+- [Design rules](references/design-rules.md): visual, interaction and anti-pattern checks.
+- [Routing rules](references/routing-rules.md): map intent to the appropriate workflow.
+- [Command workflows](references/command-workflows.md): executable steps using available project tools.
+- [Management capabilities](references/pin-unpin-and-hooks.md): limits of this instruction-only bundle.
 
-- `references/design-rules.md` — general + new-project rules, absolute bans, AI slop test. **Load before producing/reviewing UI code.**
-- `references/routing-rules.md` — full routing algorithm for no-argument or ambiguous invocations. **Load when you can't map the request to a table row.**
-- `references/pin-unpin-and-hooks.md` — the `pin`/`unpin`/`hooks` management flows. **Load when the user invokes one of those.**
-- `reference/<command>.md` (singular — e.g. `reference/craft.md`, `reference/brand.md`) — vendored per-command/per-register flows from the `impeccable` npm package, resolved by Setup steps 2 and 4. Not part of this repo.
-
-Zero content was cut — every rule, example, and routing detail lives verbatim in its `references/` file.
+Upstream: [pbakaus/impeccable](https://github.com/pbakaus/impeccable). The current upstream skill 4.2.1 uses a native engine; this Wizz adaptation does not imply that engine is installed.

package/src/skills-lib/impeccable/references/command-workflows.md

@@ -0,0 +1,35 @@
+# Command workflows
+
+Apply only the workflow matching the user's request. Use the existing project tools and evidence; these procedures do not require a separate CLI.
+
+## Shape and build
+
+For `shape` or `craft`: inspect the brief and current UI; determine visitor task and surface mode; draft section/component structure and states; resolve missing material decisions; research nontrivial components through the appropriate Wizz research skill. Build when authorized, then run the verification pass described in SKILL.md.
+
+## Audit and critique
+
+For `audit`: inspect keyboard/focus, labels, contrast, errors/loading/empty states, responsive overflow, motion preferences and relevant performance evidence. For `critique`: inspect hierarchy, comprehension, navigation, density, typography, brand fit and task completion. Report prioritized findings with exact file/route and evidence. Do not equate a preference with a defect, invent scores or apply fixes during a review-only request.
+
+## Refine and adjust
+
+For `polish`, address the observed issues with the highest user impact. Other commands narrow the scope:
+
+| Commands | Inspect and change |
+|---|---|
+| typeset, layout | Type hierarchy, readable line lengths, wrapping, spacing, alignment, responsive behavior |
+| colorize, bolder, quieter | Color roles, contrast and intended emphasis within the approved direction |
+| distill, clarify | Unnecessary UI/copy complexity, labels and next-action clarity; preserve factual claims |
+| adapt, harden, onboard | Device states, errors/loading/empty states, localization, first-use guidance |
+| animate, delight, overdrive | Purposeful interaction feedback, timing, reduced-motion, rendering cost |
+| optimize | Measured or directly evidenced performance problems; verify the affected path |
+| extract | Repeated tokens/patterns that merit shared primitives without changing behavior |
+
+Inspect the target first, make the authorized edits, then verify those states. Large motion effects still require inspected sources and a fit decision.
+
+## Init and document
+
+For `init`, gather known product, audience, purpose and constraints from project/user evidence; ask only for missing material facts. For `document`, extract the actual design system from code and current screenshots. Merge into existing PRODUCT.md/DESIGN.md without discarding unrelated decisions; mark assumptions.
+
+## Live
+
+Inspect the affected interface using the available browser and current dev server. Implement scoped visual variants if requested, compare the relevant viewport/states, and keep the chosen variant. If a running app or browser is unavailable, provide a code/static assessment and state what remains unverified. Do not simulate an interactive overlay or claim a visual check occurred.

package/src/skills-lib/impeccable/references/design-rules.md

@@ -92,4 +92,4 @@ If someone could look at this interface and say "AI made that" without doubt, it
 **Category-reflex check.** Run at two altitudes; the second one catches what the first one misses.
 
 - **First-order:** if someone could guess the theme + palette from the category alone, it's the first training-data reflex. Rework the scene sentence and color strategy until the answer isn't obvious from the domain. <!-- rule:skill-slop-first-order-check -->
-- **Second-order:** if someone could guess the aesthetic family from category-plus-anti-references ("AI workflow tool that's not SaaS-cream → editorial-typographic", "fintech that's not navy-and-gold → terminal-native dark mode"), it's the trap one tier deeper. The first reflex was avoided; the second wasn't. Rework until both answers are not obvious. The brand register's [reflex-reject aesthetic lanes](reference/brand.md) list catches the currently-saturated families. <!-- rule:skill-slop-second-order-check -->
+- **Second-order:** if someone could guess the aesthetic family from category-plus-anti-references ("AI workflow tool that's not SaaS-cream → editorial-typographic", "fintech that's not navy-and-gold → terminal-native dark mode"), it's the trap one tier deeper. The first reflex was avoided; the second wasn't. Rework until both answers are not obvious. Ground the direction in the user's brief and inspected references instead of swapping one generic aesthetic for another. <!-- rule:skill-slop-second-order-check -->

package/src/skills-lib/impeccable/references/pin-unpin-and-hooks.md

@@ -1,17 +1,7 @@
-# Pin/unpin and hooks management commands
+# Pin, unpin and hooks
 
-Load this file when the user invokes `pin`, `unpin`, or `hooks` (with any argument). Covers: creating/removing standalone command shortcuts, and managing the design detector hook that auto-runs after direct UI file edits.
+The Wizz instruction-only adaptation does not ship the upstream management runtime. `pin`, `unpin` and `hooks` are therefore not executable through this bundle.
 
-## Pin / Unpin
+If asked to manage them, first inspect whether the project separately installed the official Impeccable runtime. If present, consult its installed help and current official documentation and use only commands it actually supports. If absent, explain the missing capability and prepare an installation plan if requested. Do not install another runtime automatically during UI work.
 
-**Pin** creates a standalone shortcut so `{{command_prefix}}<command>` invokes `{{command_prefix}}impeccable <command>` directly. **Unpin** removes it. The script writes to every harness directory present in the project.
-
-```bash
-node {{scripts_path}}/pin.mjs <pin|unpin> <command>
-```
-
-Valid `<command>` is any command from the table above. Report the script's result concisely. Confirm the new shortcut on success, relay stderr verbatim on error.
-
-## Hooks
-
-`{{command_prefix}}impeccable hooks <on|off|status|ignore-rule|ignore-file|ignore-value|reset>` manages the design detector hook for this project. The hook auto-runs the detector after direct UI file edits and surfaces findings as system reminders. Full flow is in [reference/hooks.md](reference/hooks.md); load it when the user invokes `{{command_prefix}}impeccable hooks` with any argument.
+UI audit and polish remain available through the bundled [command-workflows](command-workflows.md). Never report a hook or detector as active based solely on these instructions.

package/src/skills-lib/impeccable/references/routing-rules.md

@@ -1,28 +1,11 @@
-# Routing rules — how to pick a command
+# Routing rules
 
-Load this file whenever the skill is invoked without an explicit sub-command, or when the user's intent doesn't obviously name one of the commands in the table. Covers: the no-argument menu logic (reading context-signals.mjs and detect.mjs, picking the 2-3 highest-value next commands), first-word command matching, intent-to-command mapping, and the fallback general design invocation path.
+Use the user's requested action and target. A clearly implied action is enough to start; do not ask them to choose a command they already described.
 
-### Routing rules
+- Review or diagnose: `audit` for technical defects; `critique` for visual/UX reasoning. Report findings without editing unless authorized.
+- Fix or refine existing UI: `polish`, or the specific adjustment command. Preserve existing identity and behavior outside scope.
+- New page or redesign: `shape`, then the authorized build; use the source-research skills before nontrivial UI code.
+- Capture existing context: `document` for design evidence, `init` for product context. Missing PRODUCT.md does not block a narrow fix.
+- No task or target: inspect available project context and recommend up to three useful actions with evidence; ask for the missing objective.
 
-1. **No argument**: the user is asking "what should I do?" Make the menu context-aware instead of static. Setup has already run `context.mjs`; if that reported `NO_PRODUCT_MD` you are already in init (setup), so finish that and skip this. Otherwise run `node {{scripts_path}}/context-signals.mjs` once and read its JSON, then lead with the **2-3 highest-value next commands**, each with a one-line reason pulled from the signals, followed by the full menu (the table above, grouped by category). **Never auto-run a command; the recommendation is a suggestion the user confirms.**
-
-   Reason over the signals; there is no score to obey:
-   - `setup.hasDesign` false while `setup.hasCode` true → `document` (capture the visual system).
-   - `critique.latest` is `null` → the project has never been critiqued; for a set-up project with a real surface, offering `/impeccable critique <surface>` is a strong default.
-   - `critique.latest` with a low `score` or non-zero `p0` / `p1` → `polish` (it reads that snapshot as its backlog), or re-run `critique` if the snapshot looks stale.
-   - `git.changedFiles` pointing at one surface → scope `audit` or `polish` to those files specifically, naming them.
-   - `devServer.running` true → `live` is available for in-browser iteration; if false, don't lead with `live`.
-   - Otherwise group by intent exactly as init's "Recommend starting points" step does (build new / improve what's there / iterate visually), tailored to `setup.register`.
-
-   **If `scan.targets` is non-empty, run `node {{scripts_path}}/detect.mjs --json <scan.targets joined by spaces>` once** (the bundled detector over local files: no network, no npx). `scan.via` tells you what they are: `git-changes` (the markup/style files in your dirty tree, the most relevant set), `source-dir` (e.g. `src`, `app`), `html`, or `root`. Fold the hits into your picks: many quality / contrast hits → `audit` or `polish`; a specific slop family → the matching command (gradient text or eyebrows → `quieter` / `typeset`, flat or gray palette → `colorize`, and so on). It's a real, current signal that beats guessing. If detect errors or the tree is large and slow, skip it and recommend the user run `audit` themselves; never block the suggestion on it.
-
-   Keep it to 2-3 pointed picks with the exact command to type. The menu stays the fallback; the recommendation is the lede.
-2. **First word matches a command** (table above OR `pin` / `unpin` / `hooks`): load its reference file and follow its instructions. Everything after the command name is the target.
-3. **First word doesn't match, but the intent clearly maps to one command** (e.g. "fix the spacing" → `layout`, "rewrite this error message" → `clarify`, "the colors feel flat" → `colorize`): load that command's reference and proceed as if invoked. If two commands could fit, ask once which.
-4. **No clear command match**: general design invocation. Apply the setup steps, the General rules, and the loaded register reference, using the full argument as context.
-
-Setup (context gathering, register) is already loaded by then; sub-commands don't re-invoke `{{command_prefix}}impeccable`.
-
-If the first word is `craft`, setup still runs first, but [reference/craft.md](reference/craft.md) owns the rest of the flow. If setup invokes `init` as a blocker, finish init, refresh context, then resume the original command and target.
-
-`teach` is a deprecated alias for `init`: if the user types it, load [reference/init.md](reference/init.md) and proceed as if they ran `init`.
+Read [command-workflows](command-workflows.md) for the selected action. Reuse context from the current handoff; do not re-invoke router or maestro. Do not invoke absent detector/context scripts.

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

@@ -1,6 +1,6 @@
 ---
 name: premium-landing-ui-researcher
-description: Pesquisar animações, componentes, referências visuais e padrões de conversão para criar landing pages premium em React, Next.js, Tailwind, shadcn/ui, Framer Motion, Three.js e React Three Fiber. Use quando o pedido envolver analisar projeto existente; classificar nível de complexidade do site (básico a 3D high-end/Signature); escolher componentes/animações; melhorar UI genérica; criar landing page completa, transformar oferta em página estratégica, dashboard SaaS, site de autoridade/portfolio (agência, estúdio, consultoria, marca pessoal, lead passivo), case studies/selected work editoriais, ou experiência 3D cinematográfica para marcas premium; buscar referências em fontes premium (React Bits, Cult UI, Watermelon UI, Skiper UI, 21st.dev via Magic MCP/CLI, outras em references/component-sources.md); ou escolher motion engine (GSAP, anime.js, Framer Motion, Three.js/R3F) para scroll storytelling.
+description: Pesquisar animações, componentes, referências visuais e padrões de conversão para criar landing pages premium em React, Next.js, Tailwind, shadcn/ui, Framer Motion, Three.js e React Three Fiber. Use quando o pedido envolver analisar projeto existente; classificar nível de complexidade do site (básico a 3D high-end/Signature); escolher componentes/animações; melhorar UI genérica; criar landing page completa, transformar oferta em página estratégica, dashboard SaaS, site de autoridade/portfolio (agência, estúdio, consultoria, marca pessoal, lead passivo), case studies/selected work editoriais, ou experiência 3D cinematográfica para marcas premium; buscar referências em fontes premium (React Bits, Cult UI, Watermelon UI, Skiper UI, Componentry, outras em references/component-sources.md); ou escolher motion engine (GSAP, anime.js, Framer Motion, Three.js/R3F) para scroll storytelling.
 ---
 
 # Premium Landing UI Researcher
@@ -9,9 +9,9 @@ Estrategista autônomo de landing pages premium, UI SaaS e experiências visuais
 
 ## Gate 1: Source-First (sempre, antes de qualquer código de UI)
 
-Esta skill existe porque escrever shaders, animações, hovers e componentes do zero NÃO é o caminho. O caminho é curar componentes, animações e shaders maduros de fontes profissionais (`modelos lp/` do usuário, React Bits, Cult UI, Ali Imam, Watermelon, StyleUI, Skiper UI e, como fonte PAGA complementar, 21st.dev via Magic MCP e 21st CLI) e adaptar à marca.
+Esta skill existe porque escrever shaders, animações, hovers e componentes do zero NÃO é o caminho. O caminho é curar componentes, animações e shaders maduros de fontes profissionais (`modelos lp/` do usuário, React Bits, Cult UI, Ali Imam, Watermelon, StyleUI, Skiper UI, Componentry e registries públicos) e adaptar à marca.
 
-Regra absoluta: inspecione fontes reais, ofereça opções ao usuário, adapte à marca. Nunca recrie o que já existe maduro. Se uma fonte estiver indisponível (MCP offline, sem rede, sem permissão pra clone), declare isso explicitamente ao usuário antes de cair pro fallback de criar do zero. Nunca cair pro fallback silenciosamente. O mandato completo (anti-patterns e required pattern) está no topo de [source-first-protocol](references/source-first-protocol.md).
+Regra absoluta: inspecione fontes reais, registre evidências e recomende opções, adapte à marca. Nunca recrie o que já existe maduro. Se uma fonte estiver indisponível, registre a limitação e pesquise outra fonte pública ou local antes de justificar uma implementação própria. Nunca cair pro fallback silenciosamente. O mandato completo (anti-patterns e required pattern) está no topo de [source-first-protocol](references/source-first-protocol.md).
 
 ## Gate 2: classificar o nível do site (sempre, antes de recomendar componentes)
 
@@ -31,7 +31,7 @@ Classificar o projeto em um dos 5 níveis (regras, motion permitido/proibido e b
 2. Classificar o nível do site (Gate 2).
 3. Definir direção visual e stack.
 4. Decidir modos extras: dashboard SaaS e/ou Portfolio / Authority Mode.
-5. Checkpoints de fontes: inventário interno, Source-First Protocol completo e confirmação do usuário sobre as fontes escolhidas (Gate 1). Nunca pular silenciosamente.
+5. Checkpoints de fontes: inventário interno, Source-First Protocol completo e escolha das fontes dentro do escopo autorizado (Gate 1). Nunca pular silenciosamente.
 6. Se nível 4 ou 5: handoff pro `motion-3d-director` antes de implementar.
 7. Escrever copy completa e estrutura da página.
 8. Plano de implementação (handoff pro `implementation-planner` quando aplicável).
@@ -47,9 +47,9 @@ Classificar o projeto em um dos 5 níveis (regras, motion permitido/proibido e b
 | Handoffs pro motion-3d-director e implementation-planner, regra final do ladder | [handoffs](references/handoffs.md) |
 | SaaS Dashboard Mode e Portfolio / Authority Site Mode | [dashboard-and-portfolio-modes](references/dashboard-and-portfolio-modes.md) |
 | Processo obrigatório de 12 passos e checkpoint de honestidade | [mandatory-process](references/mandatory-process.md) |
-| Source-First Mandate completo + protocolo em 5 fases (inventário, repos em cache, Magic MCP, 21st CLI, confirmação; 21st = fonte paga complementar) | [source-first-protocol](references/source-first-protocol.md) |
+| Protocolo em 5 fases (inventário, busca pública, cache, evidências, adaptação) | [source-first-protocol](references/source-first-protocol.md) |
 | Audit Protocol: Pass 1 Taste, Pass 2 Impeccable, Pass 3 Cross-check, Pass 4 A11y/Perf | [audit-protocol](references/audit-protocol.md) |
-| Fontes de componentes (React Bits, Cult UI, Ali Imam, Watermelon, StyleUI, Skiper UI, Bklit UI, 21st.dev + 21st CLI), animation engines (GSAP, anime.js), fontes de referência e inspiração visual, Clone Policy, Paid Source Policy | [component-sources](references/component-sources.md) |
+| Fontes de componentes (React Bits, Cult UI, Ali Imam, Watermelon, StyleUI, Skiper UI, Bklit UI, Componentry), animation engines (GSAP, anime.js), fontes de referência e inspiração visual, Clone Policy, Paid Source Policy | [component-sources](references/component-sources.md) |
 | Stack default, direção visual, paletas, tipografia e regras de seleção de animação | [stack-and-visual-direction](references/stack-and-visual-direction.md) |
 | Estrutura obrigatória da landing, case studies/portfolio, copywriting, conversão e CTA externo/WhatsApp | [landing-page-strategy](references/landing-page-strategy.md) |
 | Prompts base (landing completa e hero 3D com scroll) | [prompt-templates](references/prompt-templates.md) |

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

@@ -4,70 +4,26 @@ Priorizar fontes gratuitas, open source, públicas, registry-based ou fornecidas
 
 Não depender de fontes pagas como parte central do fluxo.
 
-Fluxo recomendado de pesquisa (gratuito primeiro; 21st.dev é PAGO e entra como complemento):
+Fluxo de pesquisa (fontes públicas primeiro; registrar evidências conforme [source-first-protocol](source-first-protocol.md)):
 
 1. referências enviadas pelo usuário (`modelos lp/`, prints, links);
 2. repositórios open source autorizados: cache central em `~/.claude/design-sources/` (React Bits, Cult UI, Ali Imam, Watermelon, StyleUI) + Skiper UI via shadcn + Componentry (componentry.dev, gratuito, React animado);
 3. registries shadcn públicos;
 4. fontes de taste/motion (Impeccable, Taste Skill, Design Motion Principles, MotionSites, Vibe Code Components, Refero Styles com DESIGN.md gratuito);
 5. fontes visuais abertas (Landing Love, Godly, Design Spells, Mobbin, Refero, ScreensDesign, DesignVault, Spline, Unicorn Studio);
-6. 21st.dev (fonte PAGA, complementar, com aprovação do usuário): Magic MCP (`mcp__magic__*`) e 21st CLI (`21st search`/`get`/`add`, registry do time);
-7. hipóteses estratégicas coerentes, quando não houver acesso externo.
+6. hipóteses estratégicas coerentes, quando não houver acesso externo.
 
-## 21st.dev / Magic MCP
+## Evidências de mineração
 
-Esta skill deve usar 21st.dev diretamente quando MCP/API estiver disponível.
+Para cada recomendação, abra a demo e o código/registry do item exato. Registre busca, URL/path, revisão ou data, licença, dependências, compatibilidade e motivo de seleção ou rejeição. Não invente nomes de arquivos nem use a homepage de um catálogo como prova de que um componente foi encontrado.
 
-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.
-
-## 21st CLI: busca, inspeção e registry do time
-
-O v0 saiu do fluxo (não é mais usado). A **CLI oficial do 21st.dev** cobre busca, inspeção, instalação e publicação, direto do terminal, com o registry do time (`@wizzdigitalagency`).
-
-**Setup (uma vez):** `npm i -g @21st-dev/cli` + `21st login` (browser; em CI usar env `API_KEY_21ST`). As skills oficiais (`21st-cli-use`, `21st-registry`, `21st-design-sync`) instalam com `npx @21st-dev/cli install-skill` e ensinam o agente a publicar/editar/instalar sozinho.
-
-**Fluxo de mineração (3 passos):**
-
-1. **Buscar:** `21st search "<termo>"` (ex: `pricing table`, `hero glass`, `testimonials`), com `--type component|theme|template` quando fizer sentido.
-2. **Inspecionar:** `21st get <id>` pra ver o item antes de decidir; `21st bookmarks` lista os salvos do usuário.
-3. **Instalar/adaptar:** `21st add <user>/<slug>` ou `npx shadcn@latest add https://21st.dev/r/<user>/<slug>`; depois adaptar tokens/tipografia à marca (nunca colar cru).
-
-**Publicar de volta (registry do time):** componente maduro adaptado à marca vira ativo reutilizável: `21st publish ./Componente.tsx --to default` (multi-arquivo via `21st.json`). Temas: `21st publish-theme`. Ver skill `21st-registry`.
-
-**Complemento, não substituto, do Magic MCP:** o Magic MCP continua sendo o caminho de GERAÇÃO/refino assistido (inspiration/builder/refiner); a CLI é o caminho de CATÁLOGO/registry. Se o MCP estiver offline ou sem `MAGIC_API_KEY`, a CLI é o fallback declarado.
+Use o browser disponível para verificar animações e estados quando possível. Se a fonte estiver indisponível, registre isso e continue pelas outras fontes. Inspiração visual e código reutilizável têm critérios de evidência diferentes.
 
 **Overlap com modelos locais:** inspecionar a pasta `modelos lp/` do usuário primeiro; o que já foi minerado e salvo localmente não precisa de rede.
 
 ## Authorized Component / Code Inspection Sources
 
-Estas fontes podem ser clonadas temporariamente, com permissão do usuário, para inspecionar componentes, exemplos ou registries.
+Estas fontes são candidatas à pesquisa; verifique disponibilidade e licença do item escolhido. Siga a Clone Policy abaixo para inspecionar componentes, exemplos ou registries.
 
 ### React Bits
 
@@ -77,7 +33,7 @@ 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.
+Verificar a licença do item/revisão: em 2026-09-06 o [LICENSE.md](https://github.com/DavidHDev/react-bits/blob/0e69e737242df1d257b4e5e399b01ae1d7901375/LICENSE.md) declara MIT + Commons Clause. Código público não equivale a MIT sem restrições adicionais. Não recomendar nem listar componentes React Bits Pro como dependência obrigatória.
 
 ### Cult UI
 
@@ -100,7 +56,7 @@ 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.
+Se a estrutura do repositório estiver incerta: inspecionar docs primeiro e não assumir nomes de componentes sem verificar.
 
 ### Watermelon UI
 
@@ -128,7 +84,7 @@ Usar para: templates, landing page layouts, páginas prontas, seções instaláv
 ### Animmaster Lib
 
 - Site: https://animmasterlib.dev/ — **fonte PAGA** (300 componentes animados PRO, HTML/CSS/JS/React/Next)
-- Mesmo gate de custo do 21st.dev: só com aprovação do usuário, quando as gratuitas não cobrirem
+- Só usar com acesso/custo autorizado, quando as fontes públicas não cobrirem
 - O que o usuário já comprou/baixou dela vale como recurso local (inspecionar em `modelos lp/`)
 
 ### Bklit UI
@@ -319,32 +275,9 @@ Não prometer código pronto quando a fonte for apenas visual. Não copiar visua
 
 ## 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.
+Siga a fase de cache de [source-first-protocol](source-first-protocol.md). Prefira arquivos públicos, docs e registry; clone em diretório isolado apenas quando necessário à pesquisa autorizada. Confira origem, revisão e alterações locais antes de atualizar um cache. Nunca sobrescreva trabalho local nem execute scripts do repo para apenas inspecionar código.
 
-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.
+Use somente os componentes necessários; preserve licença e atribuições. O clone de pesquisa não vira dependência permanente do app.
 
 ## Paid Source Policy
 
@@ -358,8 +291,7 @@ Remover dependência obrigatória de:
 - Cult UI Pro;
 - Skiper UI premium;
 - Spline pago;
-- Unicorn Studio pago;
-- planos pagos do 21st.dev como obrigação (o fluxo funciona no free tier).
+- Unicorn Studio pago.
 
 Usar ferramentas pagas apenas se:
 
@@ -371,4 +303,3 @@ Usar ferramentas pagas apenas se:
 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

@@ -11,10 +11,9 @@ A skill deve:
 - 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 a 21st CLI (`21st search` / `21st get` / `21st add`) para descoberta e instalação de componentes de referência;
+- abrir e inspecionar demos, código e registries públicos, registrando evidências de pesquisa;
 - usar repositórios autorizados como fonte de pesquisa;
-- clonar temporariamente repositórios autorizados apenas quando necessário e com permissão;
+- clonar temporariamente repositórios autorizados em diretório isolado apenas quando necessário à pesquisa autorizada;
 - 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;
@@ -59,4 +58,3 @@ Se o usuário não responder tudo, continuar com hipóteses estratégicas coeren
 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/mandatory-process.md

@@ -7,9 +7,9 @@ Sempre seguir este processo. **Os passos 6, 7 e 8 são CHECKPOINTS DE FONTES e d
 3. Classificar o nível do projeto.
 4. Definir direção visual.
 5. Decidir se precisa de landing, dashboard, 3D/WebGL ou combinação.
-6. **CHECKPOINT: Inventário de fontes do usuário.** Listar e inspecionar (ls + leitura mínima de READMEs/package.json) o conteúdo de `/modelos lp/` (ou pasta equivalente que o usuário tiver), do projeto atual se houver, e do cérebro/vault. Identificar quais componentes/efeitos do que ele já tem podem ser reutilizados antes de qualquer fonte externa.
-7. **CHECKPOINT: Source-First Protocol (obrigatório).** Executar o protocolo definido em references/source-first-protocol.md: invocar Magic MCP do 21st.dev, v0 via MCP, e pedir autorização pra clones temporários quando aplicável. Voltar pro usuário com **3-5 opções concretas de componentes/animações reais** com link/nome da fonte. Nunca pular este passo silenciosamente.
-8. **CHECKPOINT: Apresentar opções e obter confirmação.** Mostrar ao usuário o que cada fonte oferece e qual combinação faria sentido para a landing dele. Só prosseguir quando ele aprovar a direção das fontes escolhidas.
+6. **CHECKPOINT: Inventário de fontes do usuário.** Listar e inspecionar (ls + leitura mínima de READMEs/package.json) o projeto atual e os modelos nos caminhos fornecidos pelo usuário; reutilizar o resumo de memória do handoff. Identificar quais componentes/efeitos do que ele já tem podem ser reutilizados antes de qualquer fonte externa.
+7. **CHECKPOINT: Source-First Protocol (obrigatório).** Execute [source-first-protocol](source-first-protocol.md): busque fontes públicas, abra demos e código/registry, confira revisão, licença e dependências. Registre evidências e falhas no artefato de pesquisa; mostre 1–3 candidatos reais por componente.
+8. **CHECKPOINT: Escolher fontes.** Recomende a combinação adequada. Com direção e implementação já autorizadas, prossiga; pergunte apenas se faltar uma decisão material.
 9. Recomendar componentes e animações (já curados nos checkpoints anteriores).
 10. Escrever copy e estrutura.
 11. Sugerir plano de implementação (adaptação das fontes à marca, não recriação).
@@ -20,9 +20,9 @@ Sempre seguir este processo. **Os passos 6, 7 e 8 são CHECKPOINTS DE FONTES e d
 Antes de escrever qualquer componente, responder internamente:
 
 - Eu inspecionei o que o usuário já tem em `/modelos lp/` (ou equivalente)?
-- Eu invoquei o Magic MCP do 21st.dev, ou declarei explicitamente que está indisponível?
-- Eu pedi autorização para clonar fontes autorizadas quando elas tinham o efeito ideal (Ali Imam pra shader, React Bits pra animação, Cult UI pra section)?
-- O componente que estou prestes a escrever do zero **realmente não existe** em nenhuma das fontes inventariadas?
+- Eu abri as fontes exatas e registrei código/registry, revisão/data, licença e dependências?
+- Eu documentei candidatos aceitos/rejeitados e eventuais fontes indisponíveis?
+- O componente que estou prestes a escrever do zero ficou sem alternativa compatível nas fontes efetivamente pesquisadas, com justificativa registrada?
 
 Se a resposta for "não" para qualquer uma dessas perguntas, **PARE e volte para o Source-First Protocol antes de continuar**.
 
@@ -33,4 +33,3 @@ Se a resposta for "não" para qualquer uma dessas perguntas, **PARE e volte para
 **Entender o negócio.** Sempre identificar: negócio/produto/serviço, público-alvo, objetivo da página, oferta, diferenciais, nível de consciência do público, objeções prováveis, tom de marca, etapa do funil, ação principal desejada.
 
 **Escolher referências e componentes.** Com base no nível classificado, decidir: quais seções devem existir, quais componentes melhoram conversão, quais animações ajudam ou atrapalham, quais referências visuais combinam com a marca, quais efeitos no hero, quais elementos devem ser estáticos por performance, quais componentes criar do zero, quais vêm de fontes autorizadas. Toda animação deve ter função: clareza, desejo, profundidade, guia visual, prova de valor ou sofisticação.
-

package/src/skills-lib/premium-landing-ui-researcher/references/output-format-and-quality.md

@@ -114,11 +114,10 @@ A entrega deve parecer um trabalho premium de estratégia, copywriting, design e
 
 Antes de declarar a landing pronta, perguntar-se honestamente:
 
-- Eu **chamei o Magic MCP do 21st.dev** ou declarei que ele não estava disponível? Se não chamei nem declarei, voltar e fazer.
-- Eu **usei a 21st CLI (search/get/add)** ou declarei indisponível? Mesma regra.
+- Eu **abri demos e código/registry dos componentes recomendados** e registrei buscas, URLs/paths, revisão/data, licença, dependências e motivo da escolha?
 - Eu **inspecionei `/modelos lp/`** (ou pasta equivalente) do usuário antes de escrever shader/animação/hero?
-- Eu **pedi autorização para clones** das fontes autorizadas quando o efeito era específico (Ali Imam pra shader, React Bits pra animação)?
-- Cada componente que entreguei tem uma **fonte rastreável** (link 21st.dev, output v0, repo clonado, ou pasta do usuário), ou foi escrito do zero com declaração explícita?
+- Eu registrei fontes indisponíveis e usei cache sem sobrescrever alterações locais?
+- Cada componente que entreguei tem uma **fonte rastreável** (URL exata de código/registry, revisão do repo ou arquivo local), ou foi escrito do zero com declaração explícita?
 - Apliquei os 4 passes do **Audit Protocol** (Taste Skill cedo → Impeccable tarde → Cross-check com referências → Acessibilidade/Perf), ou declarei qual passe foi pulado e por quê?
 - O **Pass 4 (Acessibilidade + Performance)** foi executado? Esse passe nunca pode ser pulado.
 

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

@@ -1,146 +1,65 @@
-<EXTREMELY-IMPORTANT>
+# Source-First Protocol
 
-## Source-First Mandate (read this FIRST, every time)
+Antes de implementar UI não trivial, pesquise componentes reais e adapte-os à marca. O catálogo de fontes é um ponto de partida; citar um catálogo sem abrir o item não conta como pesquisa.
 
-**Esta skill existe porque escrever shaders, animações, hovers e componentes do zero NÃO é o caminho.** O caminho é **curar componentes, animações e shaders maduros de bibliotecas profissionais** (modelos lp do usuário, React Bits, Cult UI, Ali Imam, Watermelon, StyleUI, Skiper UI e, como fonte PAGA complementar, 21st.dev) e **adaptar à marca**.
+## Fase 1: Inventário do projeto
 
-Se você se pegar pensando "vou escrever um shader perlin do zero" ou "vou criar uma esfera de partículas no R3F na mão" ou "vou desenhar um SVG de carousel": **PARE**. Isso é o anti-pattern que essa skill foi feita pra prevenir.
+1. Inspecione dependências, tokens, componentes e animações existentes.
+2. Procure `modelos lp/` ou equivalente dentro do projeto e nos caminhos já fornecidos pelo usuário. Use `rg --files`; não varra a home inteira para encontrar referências.
+3. Consulte decisões já disponíveis no handoff. Reutilize ativos locais compatíveis antes de buscar fora.
 
-### Anti-pattern (NUNCA fazer)
+Registre paths reais dos recursos encontrados. Se não houver modelos locais, prossiga com fontes públicas.
 
-- ❌ Escrever um shader GLSL custom sem antes ter inspecionado Ali Imam, paper.design refs, 21st.dev e o conteúdo do usuário em `/modelos lp/`
-- ❌ Reinventar text reveal / magnetic / scroll-driven animation sem antes ter inspecionado React Bits e os modelos do usuário
-- ❌ Criar hero 3D na mão sem antes ter buscado em 21st.dev via Magic MCP e gerado variações em v0
-- ❌ Criar carousel/slider sem antes ter verificado se Embla, shadcn/ui ou 21st.dev têm componente pronto compatível com o stack
-- ❌ Desenhar mockup SVG de produto inteiro sem antes ter pedido autorização pro usuário capturar screenshot real ou usar agent-browser no projeto live
-- ❌ "Fazer tudo na mão pra ir mais rápido": isso quebra o propósito da skill
+## Fase 2: Buscar e inspecionar fontes públicas
 
-### Required pattern (SEMPRE fazer)
+Escolha fontes pelo efeito necessário, usando [component-sources](component-sources.md) e [source-links](source-links.md):
 
-Antes de escrever qualquer linha de código de UI, executar o **Source-First Protocol** (definido abaixo). A regra absoluta é:
+| Necessidade | Fontes iniciais |
+|---|---|
+| Texto animado, backgrounds, hover, partículas | React Bits, Componentry |
+| Seções de marketing, cards, botões | Cult UI, registries públicos shadcn |
+| Shader, liquid/ripple, WebGL experimental | Ali Imam, exemplos públicos compatíveis |
+| Dashboard e visualização de dados | Watermelon UI, Bklit UI |
+| Layout base | StyleUI, componentes existentes |
+| Carousel | Embla, shadcn/ui |
+| Direção visual e motion de referência | Sites fornecidos, Landing Love, Godly, Design Spells, Refero Styles |
 
-> **Inspecione fontes reais → ofereça opções ao usuário → adapte à marca. Nunca recrie o que já existe maduro.**
+Para cada componente não trivial:
 
-Se você não consegue ou não está autorizado a invocar uma fonte (MCP offline, sem permissão pra clone, sem rede), **declare isso explicitamente ao usuário** antes de cair pro fallback de criar do zero. O usuário deve poder dizer "ok, então vamos clonar Ali Imam agora" ou "tudo bem, faça na mão dessa vez". Nunca cair pro fallback silenciosamente.
+1. Formule uma busca concreta com função, estilo e stack; consulte pelo menos duas fontes adequadas quando disponíveis.
+2. Abra o item exato: demo, documentação e arquivo de código ou JSON do registry. Resultado de busca sozinho não prova compatibilidade.
+3. Inspecione imports, dependências, API, licença e variante de stack. Para documentação atual de biblioteca/CLI, use Context7; se indisponível, documentação oficial.
+4. Quando o comportamento visual importar, veja a demo com a ferramenta de browser disponível. Registre se a avaliação foi somente estática; nunca declare hover/scroll/mobile testado sem executá-lo.
+5. Se uma URL falhar, busque o endereço oficial atualizado. Se continuar inacessível, registre a falha e tente outra fonte. Não interrompa a pesquisa só porque um serviço opcional falta.
 
-</EXTREMELY-IMPORTANT>
+Componentes pagos só entram com acesso/custo já autorizado. Sites de inspiração não são fonte de código nem concedem licença de cópia.
 
-## Source-First Protocol
+## Fase 3: Cache e obtenção do código
 
-Este é o protocolo executável dos checkpoints 6, 7 e 8 do Mandatory Process. Seguir nesta ordem, declarando ao usuário o que está fazendo em cada fase.
+Cache existente de design (por exemplo `~/.claude/design-sources/`) pode ser inspecionado. Não o trate como atualizado só por existir:
 
-### Fase 1: Inventário interno (sem dependência externa)
+- Confira origem, branch, revisão e mudanças locais antes de atualizar.
+- Consulte a revisão remota quando houver rede; data de modificação da pasta não é prova de atualização.
+- Não rode `git pull`, reset ou checkout automaticamente sobre cache com alterações locais. Use uma cópia isolada ou leia o arquivo remoto.
+- Prefira docs, arquivos públicos e registry antes de clonar. Quando necessário à pesquisa autorizada, use `mktemp -d` para uma cópia isolada; não execute scripts do repositório para apenas ler código.
+- Copie somente os arquivos necessários e preserve os avisos de licença. Não adicione o repositório inteiro como dependência do app.
 
-Antes de qualquer rede ou MCP, inspecionar o que o usuário já tem:
+Sem rede, use as referências locais e declare a revisão conhecida e a limitação de atualização.
 
-1. **Pasta `modelos lp/` (ou equivalente)**: rodar `find ~ -maxdepth 6 -type d -iname "modelos*lp*"` para localizar. Listar subpastas, ler package.json e README.md de cada projeto promissor. Identificar quais já tem Lenis, GSAP, R3F, OGL, Embla, Framer Motion, shaders prontos.
-2. **Projeto atual do usuário**: se houver, listar dependências instaladas (`cat package.json`) e componentes/utilities existentes que podem ser reaproveitados.
-3. **Cérebro / vault do usuário**: usar grep nos arquivos do vault (`projetos/`, `_decisions/`) para achar padrões técnicos já documentados em projetos anteriores.
+## Fase 4: Evidência e escolha
 
-Saída desta fase: lista de **componentes, libs e padrões reaproveitáveis** com path absoluto.
+Registre no artefato de design existente (ou crie `design-research.md` na pasta de planejamento do projeto):
 
-### Fase 2: Busca nos repos de referência (cache central primeiro) — FASE PADRÃO
+| Seção/componente | Busca e fonte | Demo + código exato | Revisão/data | Licença + dependências | Evidência visual | Escolha e adaptação |
+|---|---|---|---|---|---|---|
+| Item realmente inspecionado | Termos usados e catálogo | URLs ou paths reais | SHA/tag; data se não houver versão | Verificadas ou pendentes | Testado / estático / indisponível | Aceito/rejeitado e motivo |
 
-Para cada efeito visual ainda não resolvido pela fase 1, inspecionar o **cache central de design** em `~/.claude/design-sources/` antes de qualquer clone. Só clonar se o repo não estiver em cache ou estiver desatualizado.
+Inclua também buscas sem resultado e fontes indisponíveis. Nunca preencha nomes de componentes, paths, licença ou resultados de teste por suposição.
 
-**Mapa de decisão "preciso disso → fonte":**
+Mostre 1–3 candidatos compatíveis por componente, com recomendação e custo de adaptação. Se o usuário já autorizou a implementação e definiu a direção, escolha o melhor dentro desse escopo e prossiga. Pergunte somente quando faltar decisão material de direção, acesso pago ou mudança de escopo.
 
-| Preciso de... | Cache central | Atualizar cache se necessário |
-|---|---|---|
-| Shader líquido / liquid wave / ripple / pixel grid / efeito experimental WebGL | `~/.claude/design-sources/aliimam/` | `git -C ~/.claude/design-sources/aliimam pull` |
-| Text reveal / particle effects / hover effects / animated cards / scroll effects React | `~/.claude/design-sources/react-bits/` | `git -C ~/.claude/design-sources/react-bits pull` |
-| Hero sections shadcn premium / marketing sections / botões sofisticados / cards animados | `~/.claude/design-sources/cult-ui/` | `git -C ~/.claude/design-sources/cult-ui pull` |
-| SaaS components / dashboards / product UI blocks | `~/.claude/design-sources/watermelon/` | `git -C ~/.claude/design-sources/watermelon pull` |
-| Templates / landing layouts prontos / páginas base | `~/.claude/design-sources/styleui/` | `git -C ~/.claude/design-sources/styleui pull` |
-| Componentes shadcn premium específicos | **Skiper UI** | `npx shadcn add @skiper-ui/skiperXX` (sem clone, instala direto) |
-| Charts / data viz / seções de métricas / gráficos de dashboard | **Bklit UI** | `npx shadcn@latest add @bklit/<chart>` (sem clone, registry shadcn) |
-| Scroll storytelling / pinning / timelines cinematográficas / SplitText | **GSAP** (lib npm, 100% gratuita desde a v3.13) | `npm i gsap @gsap/react` (sem clone) |
-| Microinterações imperativas leves / stagger / SVG motion / contadores | **anime.js v4** (lib npm, MIT) | `npm i animejs` (sem clone) |
+## Fase 5: Adaptar e verificar
 
-**Fluxo de uso do cache:**
-
-1. Verificar se o diretório em `~/.claude/design-sources/<repo>/` existe e tem conteúdo.
-2. Se sim: ler/grep diretamente no cache sem clonar.
-3. Se desatualizado (> 7 dias sem pull): `git -C ~/.claude/design-sources/<repo> pull --quiet` antes de inspecionar.
-4. Se o cache não existir (máquina nova): `git clone --depth=1 <url> ~/.claude/design-sources/<repo>` e seguir.
-
-**Regras de cópia para o projeto:**
-
-- Copiar APENAS o(s) componente(s) necessário(s) para `src/components/` adaptados à marca
-- Nunca adicionar o repo inteiro como dependência permanente
-- Não clonar em `.design-sources-temp/` se o cache já tem o repo: usar o cache diretamente
-
-### Fase 3: Magic MCP do 21st.dev (fonte PAGA, complementar)
-
-**Ferramentas disponíveis (chamar via ToolSearch se não estiverem carregadas):**
-
-- `mcp__magic__21st_magic_component_inspiration`: buscar referências e padrões para uma seção específica (hero, pricing, testimonials, navbar, contact dialog, etc.)
-- `mcp__magic__21st_magic_component_builder`: gerar/instalar componente alinhado ao stack do usuário
-- `mcp__magic__21st_magic_component_refiner`: refinar componente existente
-- `mcp__magic__logo_search`: logos de marcas para integrações/prova social
-
-**Gate de custo:** o 21st.dev é plano PAGO. Esta fase só roda quando as fases 1-2 não cobrirem o efeito/section necessário E com aprovação do usuário. Não é mais mínimo obrigatório.
-
-**Quando chamar (se aprovado):**
-
-- 1 chamada de `inspiration` para o **hero** (ex: liquid glass hero, particle hero, mask reveal hero)
-- 1 chamada para o **bloco principal de conversão** (ex: pricing, contact dialog, CTA group)
-- 1 chamada para **selected work / portfolio grid** se o projeto for autoridade/portfolio
-- 1 chamada para **navigation** se a direção visual exigir navbar não-padrão
-
-Se o Magic MCP não estiver disponível no ambiente: declarar ao usuário "o Magic MCP do 21st.dev não está conectado nesta sessão" e perguntar se ele quer conectar ou seguir com as outras fontes. **Não cair pro fallback de criar do zero sem essa pergunta.**
-
-### Fase 4: 21st CLI (catálogo e registry — fonte PAGA, complementar)
-
-O v0 foi removido do ecossistema. Mesmo gate de custo da Fase 3: plano pago, usar só quando as fases gratuitas não cobrirem e com aprovação do usuário. Componente do time já publicado no registry conta como recurso já pago: pode usar sem novo gate.
-
-**Fluxo resumido:**
-
-1. Checar a CLI: `command -v 21st`. Se ausente, propor (opt-in, nunca auto-rodar): `npm i -g @21st-dev/cli && npx @21st-dev/cli install-skill` e `21st login` com o usuário.
-2. Buscar: `21st search "<termo>"` (`--type component|theme|template`); inspecionar com `21st get <id>`.
-3. Instalar o escolhido no projeto: `21st add <user>/<slug>` ou `npx shadcn@latest add <url do item>`; adaptar à marca.
-4. Componente do time já publicado no registry `@wizzdigitalagency` tem prioridade sobre item público equivalente.
-
-
-
-Se a CLI não estiver instalada e o usuário recusar o install: declarar e seguir pra Fase 5 (confirmação), nunca criar do zero em silêncio.
-
-### Fase 5: Apresentação ao usuário e confirmação
-
-Antes de implementar, apresentar ao usuário uma resposta estruturada:
-
-```
-Source-First Inventory para sua landing:
-
-HERO (efeito liquid glass)
-├─ Opção A: 21st.dev → componente "X" via Magic MCP (recomendado, já compatível com Next + Tailwind)
-├─ Opção B: clonar Ali Imam → arquivo `liquid-wave.tsx` adaptado para token #FF4500
-└─ Opção C: buscar/instalar alternativa via 21st CLI (`21st search` + `21st add`)
-
-CAROUSEL DE PRODUTOS
-├─ Opção A: Embla Carousel (lib oficial, já no seu /modelos lp/ em `air-pods-max-product-showcase`)
-└─ Opção B: 21st.dev → "scroll-snap carousel" via Magic MCP
-
-TEXT REVEAL HEADLINE
-├─ Opção A: React Bits → `split-text-reveal.tsx` (precisa autorização pra clonar)
-└─ Opção B: Framer Motion na mão (fallback aceitável, padrão simples)
-
-PORTFOLIO GRID
-├─ Opção A: clonar Cult UI → `marketing-grid.tsx`
-└─ Opção B: 21st.dev → portfolio grid via Magic MCP
-
-Posso prosseguir com (A, A, A, A) ou prefere ajustar?
-```
-
-Só implementar depois da confirmação do usuário sobre quais fontes usar.
-
-### Quando é aceitável criar do zero
-
-Existem 3 casos onde é OK criar do zero, e em todos deve ser declarado ao usuário:
-
-1. **Componente trivial e específico da marca** (ex: WizzMark inline SVG do logo): sem fonte que faça sentido, custo de adaptação > custo de fazer
-2. **Após esgotar as fases 1-4** sem encontrar componente compatível, com o usuário ciente disso
-3. **Microcomponentes utilitários** (MonoLabel, Section wrapper) que são apenas estilização de tokens
-
-Para todo o resto (shaders, animações complexas, hero pieces, carousels, cards 3D, hover effects, transições), **DEVE passar pelo Source-First Protocol antes de ser escrito do zero**.
+Adapte tokens, tipografia, espaçamento, conteúdo e motion ao projeto. Verifique responsividade, teclado, foco, contraste, reduced-motion e custo de renderização conforme o componente. Vincule o resultado às fontes registradas.
 
+Criar do zero é aceitável para primitivas triviais ou quando a pesquisa documentada não encontrar opção compatível e a implementação estiver autorizada. Explique o motivo. Não declare que algo não existe em nenhum catálogo; relate apenas as fontes efetivamente pesquisadas.

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

@@ -14,14 +14,6 @@
 - Componentry (React animado, gratuito/open source, Vercel OSS): https://componentry.dev/
 - Componentry MCP (via shadcn MCP + registry `@componentry`): https://componentry.dev/docs/mcp
 - Animmaster Lib (300 componentes animados, PAGO): https://animmasterlib.dev/
-- 21st.dev: https://21st.dev/
-- 21st.dev Magic MCP: https://21st.dev/magic
-- 21st.dev MCP: https://21st.dev/mcp
-- 21st CLI (buscar/instalar/publicar via terminal): `npm i -g @21st-dev/cli` + `21st login`
-- 21st CLI skills oficiais (21st-cli-use, 21st-registry, 21st-design-sync): `npx @21st-dev/cli install-skill`
-- 21st busca: `21st search "<termo>" [--type component|theme|template]` + `21st get <id>`
-- 21st instalação: `21st add <user>/<slug>` ou `npx shadcn@latest add https://21st.dev/r/<user>/<slug>`
-- 21st API keys (CI/headless, env API_KEY_21ST): https://21st.dev/settings/api-keys
 
 ## Animation Engine Libraries (npm)
 

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

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

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

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

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

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

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

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

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

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

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

@@ -24,6 +24,8 @@ Você é o **Diretor / porta de entrada** — não o orquestrador (esse é o `wi
 
 ## Triagem e delegação (o coração do Diretor)
 
+**Skill ≠ subagente nativo:** o campo `agent:` do registry identifica uma skill de persona. Invoque-a via `Skill` (ex.: `Skill(skill="wizz-growth", args="<brief>")`), nunca como `Agent(subagent_type="wizz-growth")`. Para execução isolada, use somente um tipo anunciado pelo runtime, como `wizz-exec-sonnet`, com a skill de área e o brief no prompt. Sem executor disponível, use a skill na sessão atual; sem a skill, informe a instalação faltante. Não invente tipos de agente.
+
 **Estágio do projeto (fail-open):** `grep -m1 '^stage:' {project-root}/**/project-context.md` (ex: `_wizz-output/project-context.md`, path configurável via `output_folder`). Se achar `prototype`/`mvp`, prefira solução leve e não recomende observabilidade/infra de produção; `production`, gates de qualidade valem integralmente. Sem arquivo: siga sem mencionar estágio.
 
 Descubra o contexto: **existe `{project-root}/_wizz/`?**

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

@@ -52,7 +52,7 @@ Use esta tabela pra mapear skills/CLIs/MCPs direto **fora de projeto Wizz** (sem
 | Gerar vídeo-ad/imagem por IA (Sora/Veo/Kling) + publicar Meta | CLI `arcads` (registry `ads`; git clone + Arcads API key) | 1 |
 | Analisar/entender vídeo existente (frames + transcrição) | CLI `claude-video` (registry designer; `npx skills add bradautomates/claude-video`) | 2 |
 | Narração / voz / TTS / clonagem de voz para vídeo | CLI `voicebox` (registry designer; app local com endpoint MCP) | 2 |
-| Componentes prontos via Magic (21st.dev) | Use diretamente: `mcp__magic__21st_magic_component_inspiration` / `mcp__magic__21st_magic_component_builder` | 1 |
+| Pesquisar componentes compatíveis com o projeto | `ui-component-curator` (demos, código e registries públicos com evidências) | 1 |
 
 ## Área de Marketing / Growth
 
@@ -97,6 +97,6 @@ Quando nenhuma skill/MCP instalado cobrir o pedido, **classifique o que falta**
 
 **Falta um MCP:** informe → `claude mcp list` → consulte `skills-registry.yaml` (`mcps:`/`mcp_utility:`, com `server` pronto) → proponha `claude mcp add <id> [-e VAR=$VAR] -- <command> [args]`. Secrets sempre via env/placeholder, nunca token real.
 
-MCPs comuns: context7 (docs de libs), magic/21st (UI), supabase (Postgres), meta-ads (Meta), exa (pesquisa). Browser/E2E é sempre via CLI `agent-browser`, nunca via MCP Playwright.
+MCPs comuns: context7 (docs de libs), supabase (Postgres), meta-ads (Meta), exa (pesquisa). Browser/E2E é sempre via CLI `agent-browser`, nunca via MCP Playwright.
 
 Para paid ads Meta, o MCP `mcp-meta-ads` dá acesso real à API Meta Marketing (campanhas, ad sets, ads, métricas, criativos). Combine com `paid-ads` + `ad-creative` + `analytics-tracking`. O `META_ACCESS_TOKEN` vem de env local: nunca exponha em logs ou código commitado.