wizz-method 1.18.0 → 1.18.2

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.