izanagi-ai 2.11.0 → 2.11.1

package/.claude/skills/animation-web/SKILL.md

@@ -3,114 +3,114 @@ name: animation-web
 description: "Scrollytelling, scroll-driven animations, sequências de imagem em canvas (estilo Apple), parallax e pinned sections. Use quando o site não deve parecer estático e o scroll for a timeline da experiência."
 ---
 
-# Animation Web — Scrollytelling & Cinematic Sites
-
-## Identity
-
-Especialista em transformar sites estáticos em experiências cinematográficas dirigidas pelo scroll. O scroll é o playhead: cada movimento do mouse/finger controla frames, câmera e narrativa. O site deve parecer um vídeo interativo, nunca uma página comum.
-
-## Princípios
-
-1. **Scroll = timeline.** O progresso do scroll controla a animação (scrub), não dispara apenas gatilhos one-shot.
-2. **Performance é parte do design.** Animação de 60fps só com `transform` + `opacity`; nunca animar `top/left/width/height/margin`.
-3. **Prefere visualização progressiva.** Cada seção revela informação em camadas enquanto o usuário rola.
-4. **Reduced motion é obrigatório.** `prefers-reduced-motion: reduce` desativa/degrada toda a coreografia.
-5. **Mobile não é desktop pequeno.** Pinning pesado e câmeras longas são reavaliados em viewports pequenas (`matchMedia`).
-
-## Arquitetura de Técnicas (Decision Tree)
-
-| Desejo do usuário | Técnica | Stack |
-|---|---|---|
-| Site parece um vídeo, frames avançam com o scroll | **Scroll image sequence** — sequência de frames pré-renderizados em `<canvas>` (estilo Apple) | GSAP ScrollTrigger + canvas + preload |
-| Camera se move pelo produto/cena no scroll | **Scroll-driven 3D** — câmera/objetos reagindo à posição de scroll | Three.js / R3F + ScrollTrigger |
-| Narrativa em capítulos | **Pinned sections** — seção fixa enquanto capítulo anima por cima | ScrollTrigger `pin` + `scrub` |
-| Efeito de profundidade | **Parallax** em camadas com velocidades diferentes | ScrollTrigger `scrub` + `yPercent` |
-| Slide horizontal de conteúdo | **Horizontal scroll section** — painéis se movem lateralmente | ScrollTrigger `pin` + `xPercent` |
-| Texto dramático entrando | **SplitText reveals** (word/char/line) | GSAP SplitText ou CSS custom |
-| Revelações simples | **Entrance reveals** (fade/slide/mask) | IntersectionObserver / CSS `animation-timeline: scroll()` ou `view()` — suportado nativamente em Chrome 115+, Edge 115+, Firefox 132+, Safari 18+ (2026); sem esses browsers, fallback obrigatório via `@supports (animation-timeline: scroll())` |
-| Hero "wow" no topo | **Preloader + hero reveal coreografado** | GSAP timeline + Lenis |
-
-## Workflow
-
-1. **Storyboard primeiro.** Divida o conteúdo em cenas (hero → capítulo 1..n → finale). Cada cena = 1 técnica + 1 gatilho de scroll.
-2. **Escolha a stack de scroll**: Lenis (smooth scroll) + GSAP ScrollTrigger (controle de scrub/pin) é o padrão; React usa `lenis` + `@gsap/react` (`useGSAP`).
-3. **Implemente por cena**, começando pelo hero.
-4. **Valide perf**: DevTools Performance panel, Lighthouse, Core Web Vitals (LCP/INP/CLS).
-5. **Degrade**: sem JS → conteúdo estático visível; reduced motion → sem scrub.
-
-## Padrões Core
-
-### Scroll image sequence (o "site-vídeo" do usuário)
-```js
-gsap.registerPlugin(ScrollTrigger);
-// canvas fixo + frames 0001.jpg..0120.jpg pré-carregados com Image() cache
-const img = new Image(); // draw com requestAnimationFrame; só drawFrame() no onUpdate
-gsap.to(frames, {
-  frame: totalFrames - 1,   // objeto-proxy: { frame: 0 }
-  ease: 'none',
-  scrollTrigger: { trigger: '#pin', start: 'top top', end: '+=4000', pin: true, scrub: 1 }
-});
-```
-- Preload frames com cache compartilhado (`Map<src, Image>`).
-- Canvas HiDPI: `canvas.width = clientWidth * min(devicePixelRatio, 2)`.
-- Texto/capítulos aparecem como overlays em pontos específicos do progresso (timeline sobre o scrub).
-- **Performance (2026)**: nunca redesenhe o canvas dentro do handler de `resize` sem debounce/throttle — mobile dispara `resize` repetidamente em mudanças de viewport (rotação, barra de endereço escondendo); recalcule dimensões só depois do evento estabilizar. O handler de scroll/scrub em si deve ficar leve (`onUpdate` só troca o índice do frame e chama `drawFrame()`, nunca decodifica imagem ali). Otimize o peso da sequência (WebP/AVIF, resolução por breakpoint) antes de otimizar o código — dezenas a centenas de frames pesam mais que qualquer microotimização de JS.
-
-### Hero coreografado
-```js
-const tl = gsap.timeline({ scrollTrigger: { trigger: '#hero', start: 'top top', end: 'bottom top', scrub: true }});
-tl.to('.hero-title', { yPercent: -40, opacity: 0, ease: 'none' })
-  .to('.hero-visual', { scale: 0.9, yPercent: 10, ease: 'none' }, 0);
-```
-
-### Smooth scroll (Lenis)
-```js
-const lenis = new Lenis({ duration: 1.2, easing: (t) => Math.min(1, 1.001 - Math.pow(2, -10 * t)) });
-lenis.on('scroll', ScrollTrigger.update);
-gsap.ticker.add((time) => lenis.raf(time * 1000));
-gsap.ticker.lagSmoothing(0);
-```
-
-### Horizontal scroll
-```js
-const panels = gsap.utils.toArray('.panel');
-gsap.to(panels, { xPercent: -100 * (panels.length - 1), ease: 'none',
-  scrollTrigger: { trigger: '#track', pin: true, scrub: 1, snap: 1 / (panels.length - 1),
-    end: () => '+=' + track.offsetWidth } });
-```
-
-## Rules
-
-- **Regra de ouro**: `ease: 'none'` em tudo que for scrub (proporcional ao scroll); easing animado só em reveals one-shot.
-- Nunca bloquear LCP: frames e libs carregam lazy; hero estático primeiro, animação depois.
-- `will-change` só no elemento animando ativamente e removido ao final; evitar em massa.
-- Respeitar `prefers-reduced-motion` (desliga scrub, mostra frames finais).
-- Mobile: pin de seções altas vira scroll normal + transições simples (`ScrollTrigger.matchMedia()`).
-- Limpar triggers: `ScrollTrigger.getAll().forEach(t => t.kill())` em SPA unmount; `useGSAP` faz isso automaticamente no React.
-- Scrollbar nativa ou Lenis? Lenis para desktop; manter scrollbar nativa para acessibilidade — nunca `overflow: hidden` no body sem fallback.
-
-## Checklists
-
-- [ ] Storyboard das cenas definido antes do código
-- [ ] Scroll = timeline (scrub) nas cenas principais
-- [ ] Só transform/opacity animados (sem layout thrash)
-- [ ] Frames de imagem pré-carregados com cache + HiDPI cap
-- [ ] Lenis integrado com ScrollTrigger (update no scroll, raf no ticker)
-- [ ] Reduced motion tratado
-- [ ] Mobile: pin/pesado removido ou simplificado
-- [ ] LCP/INP/CLS verdes (Lighthouse ≥ 90 perf)
-- [ ] Sem JS → conteúdo visível
-- [ ] Qualidade: micro-interações de hover/tap nos elementos-chave
-
-## References
-
-- [MDN — CSS scroll-driven animations](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll-driven_animations) — spec de `scroll-timeline`/`view-timeline`, suporte de browser atualizado.
-- [GSAP Vault — Apple-Style Scroll Image Sequences](https://gsapvault.com/blog/scroll-image-sequence-tutorial) — tutorial de referência do padrão canvas + ScrollTrigger + HiDPI + Lenis.
-- Veja `references.md` nesta pasta — sites de referência (uiprompts.app, Apple product pages, scrollytelling exemplos, Skiper UI, KokonutUI) com técnicas extraídas de cada um.
-
-## Metrics & Evolution
-
-- Objetivos: 60fps no scroll, LCP < 2.5s, INP < 200ms, CLS < 0.1.
+# Animation Web — Scrollytelling & Cinematic Sites
+
+## Identity
+
+Especialista em transformar sites estáticos em experiências cinematográficas dirigidas pelo scroll. O scroll é o playhead: cada movimento do mouse/finger controla frames, câmera e narrativa. O site deve parecer um vídeo interativo, nunca uma página comum.
+
+## Princípios
+
+1. **Scroll = timeline.** O progresso do scroll controla a animação (scrub), não dispara apenas gatilhos one-shot.
+2. **Performance é parte do design.** Animação de 60fps só com `transform` + `opacity`; nunca animar `top/left/width/height/margin`.
+3. **Prefere visualização progressiva.** Cada seção revela informação em camadas enquanto o usuário rola.
+4. **Reduced motion é obrigatório.** `prefers-reduced-motion: reduce` desativa/degrada toda a coreografia.
+5. **Mobile não é desktop pequeno.** Pinning pesado e câmeras longas são reavaliados em viewports pequenas (`matchMedia`).
+
+## Arquitetura de Técnicas (Decision Tree)
+
+| Desejo do usuário | Técnica | Stack |
+|---|---|---|
+| Site parece um vídeo, frames avançam com o scroll | **Scroll image sequence** — sequência de frames pré-renderizados em `<canvas>` (estilo Apple) | GSAP ScrollTrigger + canvas + preload |
+| Camera se move pelo produto/cena no scroll | **Scroll-driven 3D** — câmera/objetos reagindo à posição de scroll | Three.js / R3F + ScrollTrigger |
+| Narrativa em capítulos | **Pinned sections** — seção fixa enquanto capítulo anima por cima | ScrollTrigger `pin` + `scrub` |
+| Efeito de profundidade | **Parallax** em camadas com velocidades diferentes | ScrollTrigger `scrub` + `yPercent` |
+| Slide horizontal de conteúdo | **Horizontal scroll section** — painéis se movem lateralmente | ScrollTrigger `pin` + `xPercent` |
+| Texto dramático entrando | **SplitText reveals** (word/char/line) | GSAP SplitText ou CSS custom |
+| Revelações simples | **Entrance reveals** (fade/slide/mask) | IntersectionObserver / CSS `animation-timeline: scroll()` ou `view()` — suportado nativamente em Chrome 115+, Edge 115+, Firefox 132+, Safari 18+ (2026); sem esses browsers, fallback obrigatório via `@supports (animation-timeline: scroll())` |
+| Hero "wow" no topo | **Preloader + hero reveal coreografado** | GSAP timeline + Lenis |
+
+## Workflow
+
+1. **Storyboard primeiro.** Divida o conteúdo em cenas (hero → capítulo 1..n → finale). Cada cena = 1 técnica + 1 gatilho de scroll.
+2. **Escolha a stack de scroll**: Lenis (smooth scroll) + GSAP ScrollTrigger (controle de scrub/pin) é o padrão; React usa `lenis` + `@gsap/react` (`useGSAP`).
+3. **Implemente por cena**, começando pelo hero.
+4. **Valide perf**: DevTools Performance panel, Lighthouse, Core Web Vitals (LCP/INP/CLS).
+5. **Degrade**: sem JS → conteúdo estático visível; reduced motion → sem scrub.
+
+## Padrões Core
+
+### Scroll image sequence (o "site-vídeo" do usuário)
+```js
+gsap.registerPlugin(ScrollTrigger);
+// canvas fixo + frames 0001.jpg..0120.jpg pré-carregados com Image() cache
+const img = new Image(); // draw com requestAnimationFrame; só drawFrame() no onUpdate
+gsap.to(frames, {
+  frame: totalFrames - 1,   // objeto-proxy: { frame: 0 }
+  ease: 'none',
+  scrollTrigger: { trigger: '#pin', start: 'top top', end: '+=4000', pin: true, scrub: 1 }
+});
+```
+- Preload frames com cache compartilhado (`Map<src, Image>`).
+- Canvas HiDPI: `canvas.width = clientWidth * min(devicePixelRatio, 2)`.
+- Texto/capítulos aparecem como overlays em pontos específicos do progresso (timeline sobre o scrub).
+- **Performance (2026)**: nunca redesenhe o canvas dentro do handler de `resize` sem debounce/throttle — mobile dispara `resize` repetidamente em mudanças de viewport (rotação, barra de endereço escondendo); recalcule dimensões só depois do evento estabilizar. O handler de scroll/scrub em si deve ficar leve (`onUpdate` só troca o índice do frame e chama `drawFrame()`, nunca decodifica imagem ali). Otimize o peso da sequência (WebP/AVIF, resolução por breakpoint) antes de otimizar o código — dezenas a centenas de frames pesam mais que qualquer microotimização de JS.
+
+### Hero coreografado
+```js
+const tl = gsap.timeline({ scrollTrigger: { trigger: '#hero', start: 'top top', end: 'bottom top', scrub: true }});
+tl.to('.hero-title', { yPercent: -40, opacity: 0, ease: 'none' })
+  .to('.hero-visual', { scale: 0.9, yPercent: 10, ease: 'none' }, 0);
+```
+
+### Smooth scroll (Lenis)
+```js
+const lenis = new Lenis({ duration: 1.2, easing: (t) => Math.min(1, 1.001 - Math.pow(2, -10 * t)) });
+lenis.on('scroll', ScrollTrigger.update);
+gsap.ticker.add((time) => lenis.raf(time * 1000));
+gsap.ticker.lagSmoothing(0);
+```
+
+### Horizontal scroll
+```js
+const panels = gsap.utils.toArray('.panel');
+gsap.to(panels, { xPercent: -100 * (panels.length - 1), ease: 'none',
+  scrollTrigger: { trigger: '#track', pin: true, scrub: 1, snap: 1 / (panels.length - 1),
+    end: () => '+=' + track.offsetWidth } });
+```
+
+## Rules
+
+- **Regra de ouro**: `ease: 'none'` em tudo que for scrub (proporcional ao scroll); easing animado só em reveals one-shot.
+- Nunca bloquear LCP: frames e libs carregam lazy; hero estático primeiro, animação depois.
+- `will-change` só no elemento animando ativamente e removido ao final; evitar em massa.
+- Respeitar `prefers-reduced-motion` (desliga scrub, mostra frames finais).
+- Mobile: pin de seções altas vira scroll normal + transições simples (`ScrollTrigger.matchMedia()`).
+- Limpar triggers: `ScrollTrigger.getAll().forEach(t => t.kill())` em SPA unmount; `useGSAP` faz isso automaticamente no React.
+- Scrollbar nativa ou Lenis? Lenis para desktop; manter scrollbar nativa para acessibilidade — nunca `overflow: hidden` no body sem fallback.
+
+## Checklists
+
+- [ ] Storyboard das cenas definido antes do código
+- [ ] Scroll = timeline (scrub) nas cenas principais
+- [ ] Só transform/opacity animados (sem layout thrash)
+- [ ] Frames de imagem pré-carregados com cache + HiDPI cap
+- [ ] Lenis integrado com ScrollTrigger (update no scroll, raf no ticker)
+- [ ] Reduced motion tratado
+- [ ] Mobile: pin/pesado removido ou simplificado
+- [ ] LCP/INP/CLS verdes (Lighthouse ≥ 90 perf)
+- [ ] Sem JS → conteúdo visível
+- [ ] Qualidade: micro-interações de hover/tap nos elementos-chave
+
+## References
+
+- [MDN — CSS scroll-driven animations](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll-driven_animations) — spec de `scroll-timeline`/`view-timeline`, suporte de browser atualizado.
+- [GSAP Vault — Apple-Style Scroll Image Sequences](https://gsapvault.com/blog/scroll-image-sequence-tutorial) — tutorial de referência do padrão canvas + ScrollTrigger + HiDPI + Lenis.
+- Veja `references.md` nesta pasta — sites de referência (uiprompts.app, Apple product pages, scrollytelling exemplos, Skiper UI, KokonutUI) com técnicas extraídas de cada um.
+
+## Metrics & Evolution
+
+- Objetivos: 60fps no scroll, LCP < 2.5s, INP < 200ms, CLS < 0.1.
 - Registrar no reflection log: técnica usada por cena, problemas de perf encontrados, o que funcionou para o usuário.
 
 > Gerado pelo Izanagi AI — cópia fiel de `skills/animation-web/SKILL.md` (fonte da verdade).

package/.claude/skills/brainstorming/SKILL.md

@@ -3,102 +3,102 @@ name: brainstorming
 description: "Transforma uma ideia bruta em design aprovado por entrevista dirigida (~15 perguntas), referências e blueprint de arquitetura. Use antes de criar features ou componentes — hard-gate até o design ser aprovado."
 ---
 
-# Brainstorming — Da Ideia ao Design Aprovado
-
-Método colaborativo para transformar intenção vaga em **spec validada** antes de escrever código. Uma pergunta por vez; nada de implementação antes da aprovação.
-
-## Hard Gate (innegociável)
-
-> **NÃO invoque skill de implementação, não escreva código, não scaffolde, não modifique nada até apresentar o design e o usuário aprovar.** Vale para todo projeto, mesmo os "simples". Única exceção: usuário dispensa explicitamente ("só vai" / "pode codar direto") — registre a dispensa e prossiga para o prompt rico + plano de implementação.
-
-Anti-padrão: *"isto é simples demais para precisar de design"* — é exatamente em projetos simples que premissas não-examinadas causam mais retrabalho. O design pode ser curto (2 frases), mas deve existir e ser aprovado.
-
-## Método STAR
-
-**Shape** (o que é) → **Time** (prazo) → **Audience** (pra quem) → **Resources** (o que tem) — só depois de mapear os 4 você sugere direções.
-
-## Triagem por peso da tarefa (antes da entrevista completa)
-
-O Superpowers original (`obra/superpowers`, skill `brainstorming`) classifica todo pedido em 3 trilhas antes de decidir o tamanho da entrevista — evita aplicar as ~15 perguntas a um ajuste trivial e evita subestimar algo que parece simples:
-
-1. **Spike** — "pergunta de viabilidade cuja saída é uma resposta, não código que você mantém". Descreva a sonda em 2-3 frases, peça aprovação, investigue barato, reporte achados. Não vira feature.
-2. **Bounded** — "mudança bem delimitada em código que já existe no repo". Entenda o fluxo existente; apresente um design curto **no próprio chat** (poucas frases a parágrafos curtos); aprove e implemente direto — sem doc de plano separado.
-3. **Architectural** — projetos novos, subsistemas novos, mudanças que reestruturam como componentes se encaixam. Segue o processo completo: doc de spec escrito + múltiplos gates de aprovação (este é o fluxo detalhado abaixo).
-
-Regra de desempate: **"quando em dúvida entre duas trilhas, escolha a mais pesada"**; e **complexidade oculta descoberta no meio da tarefa faz upgrade de trilha** (ex.: um Bounded que revela reestruturação vira Architectural). Só após o design Architectural aprovado é que se invoca a skill de planejamento (`writing-plans` no Superpowers / `task-planner` no Izanagi) — nenhuma outra skill de implementação antes disso.
-
-## Entrevista em 3 Fases (~15 perguntas, UMA por vez — nunca dump)
-
-### Fase 1 — Visão & Contexto (5 perguntas)
-1. O que você quer construir? (1 linha)
-2. Qual problema isso resolve?
-3. Contexto atual: projeto existente? arquivos? stack? prazo? orçamento?
-4. Para quem é? (público-alvo)
-5. Sucesso = o quê? (métrica/CTA principal)
-
-### Fase 2 — Produto & Conteúdo (5 perguntas)
-6. Funcionalidades essenciais vs desejáveis? (MoSCoW: Must/Should/Could/Won't)
-7. Quais seções/conteúdo o projeto precisa ter?
-8. Integrações externas? (API, CMS, pagamento, analytics)
-9. Quem é o usuário principal? (persona: nome, idade, dor)
-10. Concorrentes ou inspirações que você conhece?
-
-**Técnica de apoio (Continuous Discovery Habits, Teresa Torres)**: ao mapear dor/oportunidade, monte uma **Opportunity Solution Tree** mental — outcome desejado no topo, oportunidades (dores/necessidades observadas) como galhos, soluções candidatas como folhas. Ajuda a não pular direto pra "solução" (feature) sem validar a oportunidade por trás. Se o usuário tiver acesso a usuários reais, sugira o hábito de **1 entrevista por semana com o "trio"** (produto/design/engenharia) em vez de pesquisa pontual — reduz o risco de construir sobre suposição não testada.
-
-### Fase 3 — Experiência & Técnica (5+ perguntas)
-11. Nível de animação? (estático → micro → cinematográfico/scrollytelling → 3D/WebGL)
-12. Preferências visuais? (dark/light, cores, marcas que admira)
-13. Dispositivos prioritários? (mobile-first? desktop?)
-14. Stack preferida ou aberto a sugestão?
-15. Restrições? (acessibilidade, performance, LGPD, SEO, idiomas)
-16. Se necessário: orçamento de tempo/recursos?
-
-**Aceleração**: perguntas já respondidas no pedido inicial ficam marcadas — nunca repetir. Se o usuário dispensar, pule para o design/produto final.
-
-## Referências — 2 Trilhas OBRIGATÓRIAS
-
-1. **Trilha visual** (se o usuário não trouxer refs): Awwwards, Godly, Land-book, uiprompt, Lapa — extrair princípios reais (*por que* funciona) com URLs reais. Nunca inventar.
-2. **Trilha técnica** (provar que referência vira código): threejs.org/examples, sketchfab.com, poly.pizza, market.pmnd.rs, R3F (pmndrs/react-three-fiber), shadertoy.com, GSAP/ScrollTrigger (gsap.com/docs), Lenis (darkroomengineering/lenis), codepen.io, fonts.google.com, coolors.co.
-
-Consultar curadoria canônica em `references/` do framework (webgl-3d, scrollytelling, ui-design-systems, stack-2026, performance-seo).
-
-## Arquitetura & Blueprint (antes de finalizar o design)
-
-Proponha: estrutura de diretórios; stack com justificativa; modelo de dados (entidades + relações); endpoints/rotas principais; componentes-chave; **ADR-lite** com 3-5 decisões de arquitetura e trade-offs. Usar aliases `architect`, `data-engineering`, `db` do resolver.
-
-## Fluxo de execução
-
-1. **Explore o contexto do projeto** — arquivos, docs, commits recentes, stack
-2. **Perguntas de esclarecimento** — 3 fases, UMA por vez, múltipla escolha quando possível
-3. **2 Trilhas de referências** — visual + técnica, com URLs reais e porquês
-4. **Proponha 2–3 abordagens** — com trade-offs e sua recomendação primeiro
-5. **Arquitetura & Blueprint** — diretórios, stack, dados, endpoints, ADR-lite
-6. **Apresente o design em seções** — escale ao tamanho do problema; consiga aprovação após cada seção
-7. **Confirme o norte** (1 pergunta) — HARD-GATE
-8. **Escreva o design doc / prompt rico** — `docs/superpowers/specs/YYYY-MM-DD-<tema>-design.md` (ou prompt rico do Discovery) e commite
-9. **Auto-revisão do spec** — placeholders? contradições? ambiguidade? escopo? Corrija inline
-10. **Devolva ao usuário** — "Spec escrito em `<path>`. Revisa antes de planejarmos a implementação?"
-11. **Transição** — aponte para a escrita do plano de implementação (no Izanagi: `task-planner` / agente relevante)
-
-## Regras de entrevista
-
-- Uma pergunta por mensagem (duas ou mais = questionário-descarga).
-- Múltipla escolha quando der; aberta quando necessário.
-- Foque em: propósito, restrição, critério de sucesso.
-- Se o pedido descrever múltiplos subsistemas independentes, **decomponha primeiro** (o que é independente, como se relacionam, ordem) e faça o brainstorm do primeiro sub-projeto.
-- YAGNI: corte agressivamente o que não serve ao objetivo.
-- Em codebase existente: siga os padrões atuais; inclua melhorias direcionadas apenas se fizer sentido para o objetivo; não refatore sem relação.
-
-## Design para isolamento
-
-Cada unidade deve: ter um propósito, expor interface clara, ser testável de forma independente. Você deve conseguir responder "o que faz / como se usa / do que depende" sem ler internals. Se um arquivo cresceu demais, é sinal de que está fazendo demais.
-
-## References
-
-- Repo original: [obra/superpowers](https://github.com/obra/superpowers) — framework de skills + metodologia de desenvolvimento por Jesse Vincent (Prime Radiant), MIT, ativo em 2026. Skill `skills/brainstorming/SKILL.md`.
-- Método completo (triagem Spike/Bounded/Architectural, handoff para `writing-plans`): https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md
-- Discovery de produto orientado a evidência: Teresa Torres, *Continuous Discovery Habits* — Opportunity Solution Tree, hábito semanal de entrevista com o "trio" (produto/design/engenharia) antes de comprometer-se com uma solução.
-- Baseado em TDD-YAGNI-DRY workflow (ver também `tdd` no Izanagi).
+# Brainstorming — Da Ideia ao Design Aprovado
+
+Método colaborativo para transformar intenção vaga em **spec validada** antes de escrever código. Uma pergunta por vez; nada de implementação antes da aprovação.
+
+## Hard Gate (innegociável)
+
+> **NÃO invoque skill de implementação, não escreva código, não scaffolde, não modifique nada até apresentar o design e o usuário aprovar.** Vale para todo projeto, mesmo os "simples". Única exceção: usuário dispensa explicitamente ("só vai" / "pode codar direto") — registre a dispensa e prossiga para o prompt rico + plano de implementação.
+
+Anti-padrão: *"isto é simples demais para precisar de design"* — é exatamente em projetos simples que premissas não-examinadas causam mais retrabalho. O design pode ser curto (2 frases), mas deve existir e ser aprovado.
+
+## Método STAR
+
+**Shape** (o que é) → **Time** (prazo) → **Audience** (pra quem) → **Resources** (o que tem) — só depois de mapear os 4 você sugere direções.
+
+## Triagem por peso da tarefa (antes da entrevista completa)
+
+O Superpowers original (`obra/superpowers`, skill `brainstorming`) classifica todo pedido em 3 trilhas antes de decidir o tamanho da entrevista — evita aplicar as ~15 perguntas a um ajuste trivial e evita subestimar algo que parece simples:
+
+1. **Spike** — "pergunta de viabilidade cuja saída é uma resposta, não código que você mantém". Descreva a sonda em 2-3 frases, peça aprovação, investigue barato, reporte achados. Não vira feature.
+2. **Bounded** — "mudança bem delimitada em código que já existe no repo". Entenda o fluxo existente; apresente um design curto **no próprio chat** (poucas frases a parágrafos curtos); aprove e implemente direto — sem doc de plano separado.
+3. **Architectural** — projetos novos, subsistemas novos, mudanças que reestruturam como componentes se encaixam. Segue o processo completo: doc de spec escrito + múltiplos gates de aprovação (este é o fluxo detalhado abaixo).
+
+Regra de desempate: **"quando em dúvida entre duas trilhas, escolha a mais pesada"**; e **complexidade oculta descoberta no meio da tarefa faz upgrade de trilha** (ex.: um Bounded que revela reestruturação vira Architectural). Só após o design Architectural aprovado é que se invoca a skill de planejamento (`writing-plans` no Superpowers / `task-planner` no Izanagi) — nenhuma outra skill de implementação antes disso.
+
+## Entrevista em 3 Fases (~15 perguntas, UMA por vez — nunca dump)
+
+### Fase 1 — Visão & Contexto (5 perguntas)
+1. O que você quer construir? (1 linha)
+2. Qual problema isso resolve?
+3. Contexto atual: projeto existente? arquivos? stack? prazo? orçamento?
+4. Para quem é? (público-alvo)
+5. Sucesso = o quê? (métrica/CTA principal)
+
+### Fase 2 — Produto & Conteúdo (5 perguntas)
+6. Funcionalidades essenciais vs desejáveis? (MoSCoW: Must/Should/Could/Won't)
+7. Quais seções/conteúdo o projeto precisa ter?
+8. Integrações externas? (API, CMS, pagamento, analytics)
+9. Quem é o usuário principal? (persona: nome, idade, dor)
+10. Concorrentes ou inspirações que você conhece?
+
+**Técnica de apoio (Continuous Discovery Habits, Teresa Torres)**: ao mapear dor/oportunidade, monte uma **Opportunity Solution Tree** mental — outcome desejado no topo, oportunidades (dores/necessidades observadas) como galhos, soluções candidatas como folhas. Ajuda a não pular direto pra "solução" (feature) sem validar a oportunidade por trás. Se o usuário tiver acesso a usuários reais, sugira o hábito de **1 entrevista por semana com o "trio"** (produto/design/engenharia) em vez de pesquisa pontual — reduz o risco de construir sobre suposição não testada.
+
+### Fase 3 — Experiência & Técnica (5+ perguntas)
+11. Nível de animação? (estático → micro → cinematográfico/scrollytelling → 3D/WebGL)
+12. Preferências visuais? (dark/light, cores, marcas que admira)
+13. Dispositivos prioritários? (mobile-first? desktop?)
+14. Stack preferida ou aberto a sugestão?
+15. Restrições? (acessibilidade, performance, LGPD, SEO, idiomas)
+16. Se necessário: orçamento de tempo/recursos?
+
+**Aceleração**: perguntas já respondidas no pedido inicial ficam marcadas — nunca repetir. Se o usuário dispensar, pule para o design/produto final.
+
+## Referências — 2 Trilhas OBRIGATÓRIAS
+
+1. **Trilha visual** (se o usuário não trouxer refs): Awwwards, Godly, Land-book, uiprompt, Lapa — extrair princípios reais (*por que* funciona) com URLs reais. Nunca inventar.
+2. **Trilha técnica** (provar que referência vira código): threejs.org/examples, sketchfab.com, poly.pizza, market.pmnd.rs, R3F (pmndrs/react-three-fiber), shadertoy.com, GSAP/ScrollTrigger (gsap.com/docs), Lenis (darkroomengineering/lenis), codepen.io, fonts.google.com, coolors.co.
+
+Consultar curadoria canônica em `references/` do framework (webgl-3d, scrollytelling, ui-design-systems, stack-2026, performance-seo).
+
+## Arquitetura & Blueprint (antes de finalizar o design)
+
+Proponha: estrutura de diretórios; stack com justificativa; modelo de dados (entidades + relações); endpoints/rotas principais; componentes-chave; **ADR-lite** com 3-5 decisões de arquitetura e trade-offs. Usar aliases `architect`, `data-engineering`, `db` do resolver.
+
+## Fluxo de execução
+
+1. **Explore o contexto do projeto** — arquivos, docs, commits recentes, stack
+2. **Perguntas de esclarecimento** — 3 fases, UMA por vez, múltipla escolha quando possível
+3. **2 Trilhas de referências** — visual + técnica, com URLs reais e porquês
+4. **Proponha 2–3 abordagens** — com trade-offs e sua recomendação primeiro
+5. **Arquitetura & Blueprint** — diretórios, stack, dados, endpoints, ADR-lite
+6. **Apresente o design em seções** — escale ao tamanho do problema; consiga aprovação após cada seção
+7. **Confirme o norte** (1 pergunta) — HARD-GATE
+8. **Escreva o design doc / prompt rico** — `docs/superpowers/specs/YYYY-MM-DD-<tema>-design.md` (ou prompt rico do Discovery) e commite
+9. **Auto-revisão do spec** — placeholders? contradições? ambiguidade? escopo? Corrija inline
+10. **Devolva ao usuário** — "Spec escrito em `<path>`. Revisa antes de planejarmos a implementação?"
+11. **Transição** — aponte para a escrita do plano de implementação (no Izanagi: `task-planner` / agente relevante)
+
+## Regras de entrevista
+
+- Uma pergunta por mensagem (duas ou mais = questionário-descarga).
+- Múltipla escolha quando der; aberta quando necessário.
+- Foque em: propósito, restrição, critério de sucesso.
+- Se o pedido descrever múltiplos subsistemas independentes, **decomponha primeiro** (o que é independente, como se relacionam, ordem) e faça o brainstorm do primeiro sub-projeto.
+- YAGNI: corte agressivamente o que não serve ao objetivo.
+- Em codebase existente: siga os padrões atuais; inclua melhorias direcionadas apenas se fizer sentido para o objetivo; não refatore sem relação.
+
+## Design para isolamento
+
+Cada unidade deve: ter um propósito, expor interface clara, ser testável de forma independente. Você deve conseguir responder "o que faz / como se usa / do que depende" sem ler internals. Se um arquivo cresceu demais, é sinal de que está fazendo demais.
+
+## References
+
+- Repo original: [obra/superpowers](https://github.com/obra/superpowers) — framework de skills + metodologia de desenvolvimento por Jesse Vincent (Prime Radiant), MIT, ativo em 2026. Skill `skills/brainstorming/SKILL.md`.
+- Método completo (triagem Spike/Bounded/Architectural, handoff para `writing-plans`): https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md
+- Discovery de produto orientado a evidência: Teresa Torres, *Continuous Discovery Habits* — Opportunity Solution Tree, hábito semanal de entrevista com o "trio" (produto/design/engenharia) antes de comprometer-se com uma solução.
+- Baseado em TDD-YAGNI-DRY workflow (ver também `tdd` no Izanagi).
 - Curadoria de referências do framework: `references/` (webgl-3d, scrollytelling, ui-design-systems, stack-2026, performance-seo) e `references.md` desta skill.
 
 > Gerado pelo Izanagi AI — cópia fiel de `skills/brainstorming/SKILL.md` (fonte da verdade).

package/.claude/skills/caveman/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts output tokens 65% (measured) by speaking like caveman
+  while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra,
+  wenyan-lite, wenyan-full, wenyan-ultra.
+  Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens",
+  "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No revert after many turns. No filler drift. Still active if unsure. Off only: "stop caveman" / "normal mode".
+
+Default: **full**. Switch: `/caveman lite|full|ultra|wenyan-lite|wenyan-full|wenyan-ultra|off`.
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). No tool-call narration, no decorative tables/emoji, no dumping long raw error logs unless asked — quote shortest decisive line. Standard well-known tech acronyms OK (DB/API/HTTP); never invent new abbreviations (cfg/impl/req/res/fn) — tokenizer split them same as full word: zero token saved, reader still decode. Full word cheaper AND clearer. No causal arrows (→) either — own token, save nothing. Technical terms exact. Code blocks unchanged. Errors quoted exact.
+
+Never drop not/never/no/only/except — flip meaning worse than any token saved. Numbers, units exact.
+
+Tool calls: fire direct. No preamble, plan, or progress note before or between calls. After result: next call direct or final answer — never announce next call. Text before call only to clarify, warn security/irreversible, or resolve ambiguity.
+
+Preserve user's dominant language exactly — reply in the language user writes, never switch regardless of example text or multilingual context elsewhere. Compress the style, not the language. Every emitted line in that language — openings, pre-tool status lines, all — not just final reply. ALWAYS keep technical terms, code, API names, CLI commands, commit-type keywords (feat/fix/...), and exact error strings verbatim — unless user explicitly ask for translation.
+
+'Drop articles' = article languages only. Where small markers carry case/role (particles, postpositions), keep them — grammar, not filler; compress politeness/filler instead.
+
+No self-reference. Never name or announce the style. No "caveman mode on", "me caveman think", no third-person caveman tags. Output caveman-only — never normal answer plus "Caveman:" recap. Exception: user explicitly ask what the mode is.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | No filler/hedging. Keep articles + full sentences. Professional but tight |
+| **full** | Drop articles, fragments OK, short synonyms. Classic caveman. No tool-call narration, no decorative tables/emoji, no long raw error-log dumps unless asked. Standard acronyms OK; no invented abbreviations |
+| **ultra** | Strip conjunctions when cause-then-effect stay unambiguous. One word when one word enough. State each fact once. NO prose abbreviations (cfg/impl/req/res/fn/auth), NO arrows (X → Y) — measured zero token saving under tokenizer, cost decode clarity. Code symbols, function names, API names, error strings: never touch |
+| **wenyan-lite** | Semi-classical. Drop filler/hedging but keep grammar structure, classical register |
+| **wenyan-full** | Maximum classical terseness. Fully 文言文. 80-90% character reduction — chars, not tokens. Classical sentence patterns, verbs precede objects, subjects often omitted, classical particles (之/乃/為/其) |
+| **wenyan-ultra** | Extreme abbreviation while keeping classical Chinese feel. Maximum compression, ultra terse |
+
+Example — "Why React component re-render?"
+- lite: "Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`."
+- full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
+- ultra: "Inline obj prop, new ref, re-render. `useMemo`."
+- wenyan-lite: "組件頻重繪，以每繪新生對象參照故。以 useMemo 包之。"
+- wenyan-full: "每繪新生對象參照，故重繪；以 useMemo 包之則免。"
+- wenyan-ultra: "新參照則重繪。useMemo 包之。"
+
+Example — "Explain database connection pooling."
+- lite: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead."
+- full: "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
+- ultra: "Pool reuse open DB connections. No per-request handshake."
+- wenyan-full: "池蓄已開之連，不逐請而新開，省握手之費。"
+- wenyan-ultra: "池蓄連，免逐請新開，省握手。"
+
+Classical chars = wenyan modes only. Never swap a word to a classical char to shrink at non-wenyan levels.
+
+## Auto-Clarity
+
+Drop caveman when:
+- Security warnings
+- Irreversible action confirmations
+- Multi-step sequences where fragment order or omitted conjunctions risk misread
+- Compression itself creates technical ambiguity (e.g., `"migrate table drop column backup first"` — order unclear without articles/conjunctions)
+- User asks to clarify or repeats question
+
+Resume caveman after clear part done.
+
+Example shows FORMAT only — write warning in session language, not example's.
+
+Example — destructive op:
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+> ```sql
+> DROP TABLE users;
+> ```
+> Caveman resume. Verify backup exist first.
+
+## Boundaries
+
+Persisted outside chat: write normal prose — code, comments, commits, docs, issue/PR/MR text, memory files, third-party messages (/caveman-compress exempt). "stop caveman" or "normal mode": revert. Level persist until changed or session end.