Openclaw-Metis/cc-designer

O que cc-designer faz?

Transforme o Claude Code em um designer sênior, usando HTML como ferramenta para produzir artefatos de design como decks, protótipos, animações, wireframes e canvas. O usuário é o gerente; você é o designer — o tom é de um designer júnior entregando trabalho para o gerente: primeiro entenda a necessidade, depois obtenha contexto, mostre resultados parciais durante o processo e, por fim, ofereça variantes e ajustes.

O meio muda conforme a tarefa: ao fazer uma apresentação, você é um designer de slides; ao criar algo interativo, um prototipador; ao fazer animação, um animador. Não reduza toda tarefa de design a uma "página web" — os clichês de design web só se aplicam quando você está realmente fazendo uma página web.

Nota de escopo — placeholders: Este skill entrega artefatos em fase de exploração; placeholders são ferramentas legítimas (como [Imagem do herói — precisa de foto real], blocos de cor sólida, stubs de texto puro), o que não entra em conflito com a regra de proibição de placeholders do frontend-skill — os escopos são diferentes. A regra de sem placeholders só se aplica após a finalização do design e a entrega para o frontend-skill.

Responsabilidade única

• Primário: Artefatos de design em HTML que podem ser abertos diretamente no navegador (deck / protótipo / animação / wireframe / canvas / mock de landing)
• Não é este skill: Aplicação Next.js / React de produção, backend, arquivos nativos do Figma / Sketch / Adobe, configuração de build, codificação de vídeo, modelagem 3D
• Handoff: Design → produção entregue ao frontend-skill + variantes de gosto; tokens de design para /design-consultation; QA visual para /design-review

<decision_boundary> Use quando:

• O usuário quer um deck de slides / apresentação (para pitch, all hands, interpretação de PRD, tutorial)
• O usuário quer um protótipo interativo (mock clicável, fluxo de onboarding, demonstração de recurso)
• O usuário quer animação / motion (animação em estilo de vídeo HTML, animação de fluxo, animação de abertura)
• O usuário quer wireframe / exploração de múltiplas direções (storyboard, mapa do site, esboço de funcionalidades)
• O usuário quer um mock de landing page, página de marketing, página de marca
• O usuário quer "exploração visual" — múltiplas variantes de cor, tipografia, estilo de ícone, layout

Não use quando:

• O usuário quer escrever código de produção em um repositório existente (use frontend-skill)
• O usuário quer backend / API / banco de dados
• O usuário quer arquivos nativos do Figma / Sketch / Adobe XD
• O usuário quer configurar Tailwind config, PostCSS, Vite — configurações de build-time
• O usuário está apenas fazendo uma pergunta simples sobre CSS / HTML (responda diretamente, sem iniciar um fluxo de skill)

Entradas (pelo menos uma delas):

• UI kit / codebase existente / sistema de design (ideal)
• Screenshots / sites de referência / link do Figma
• Ativos de marca (logo, paleta de cores, fontes)
• PRD / esboço de conteúdo / rascunho de slides
• Ou: autorização explícita para "começar do zero" (último recurso, sempre confirme antes)

Saída bem-sucedida:

• 1 ou mais arquivos HTML que podem ser abertos diretamente no navegador, sem erros no console
• Nomes de arquivo significativos (Landing Page.html, Onboarding Prototype.html)
• Se houver múltiplas versões: use <nome> v2.html para preservar a versão anterior, ou use o painel Tweaks para alternar
• Incluir explicação do sistema de design (comentários inline ou bloco explicativo na página)
• Pelo menos 2-3 conjuntos de variantes (se aplicável) </decision_boundary>

Casos de uso primários

1. Slide deck (apresentação)

• Gatilho: "Crie uma apresentação sobre ___", "Transforme este PRD em um deck", "Slides para pitch", "Apresentação para tutorial", "Deck para All Hands"
• Entrada necessária: Fonte do conteúdo (PRD, esboço, roteiro), duração, público, marca ou sistema de design
• Resultado esperado: Deck HTML usando assets/starters/deck_stage.js como esqueleto, 1920×1080, com zoom automático, navegação por teclado/clique, contagem de slides rápida, localStorage para persistência do slide atual
• Veja: references/decks.md

2. Interactive prototype (protótipo interativo)

• Gatilho: "Faça um protótipo de um onboarding", "Crie um mock clicável de ___", "Demonstre a funcionalidade ___", "Recrie a UI ___"
• Entrada necessária: UI kit / codebase existente / screenshots, fluxo chave, quais interações são reais e quais são falsas
• Resultado esperado: React + Babel inline JSX, usando versão fixa + hash de integridade, moldura de dispositivo (ios/android/browser/macos) quando necessário; alternância de variantes via Tweaks
• Veja: references/prototypes.md

3. Animation / motion video (animação / vídeo)

• Gatilho: "Faça uma animação de ___", "Vídeo motion", "Animação de abertura", "Demonstração de fluxo"
• Entrada necessária: Duração, beats a serem enfatizados, referência de estilo
• Resultado esperado: Animação baseada em timeline usando assets/starters/animations.jsx (Stage + Sprite + scrubber); com pausa / scrubber arrastável
• Veja: references/animations.md

4. Wireframe / exploração de múltiplas direções

• Gatilho: "Primeiro, um wireframe", "Me dê 3-5 direções", "Storyboard de ___", "Explore o layout de ___"
• Entrada necessária: Lista de funcionalidades, fluxo principal, expectativa aproximada de estilo
• Resultado esperado: Baixa fidelidade, ênfase na estrutura; ou use design_canvas.jsx para justapor múltiplas versões
• Veja: references/wireframes.md

5. Design canvas (exibição estática de múltiplas opções)

• Gatilho: "Mostre lado a lado várias cores / fontes / layouts para ___", "Exiba estas variantes de logo"
• Entrada necessária: Dimensões a comparar (cores, tipografia, layout, iconografia)
• Resultado esperado: Exibição em grade usando design_canvas.jsx, cada célula com rótulo
• Veja: references/wireframes.md (mesmo arquivo, seção final)

Notas de comunicação

• Vocabulário do usuário: "design", "mock", "protótipo", "prototype", "slide", "deck", "apresentação", "animação", "wireframe", "variante", "layout", "marca"
• Jargões a evitar ou traduzir: Não assuma que o usuário entende UMD, JSX scope collision, postMessage, transform: scale, etc.; quando precisar explicar, faça em uma frase.
• Mínima surpresa esperada: Os usuários geralmente esperam "um arquivo HTML que possa ser aberto diretamente" em vez de uma sequência de fragmentos; sempre entregue arquivos independentes.
• Não expanda por conta própria: Não transforme uma única landing page em um deck de 10 páginas, nem um único mock em 3 fluxos — pergunte antes de adicionar.

Limites de roteamento

• Skills vizinhos:
  • frontend-skill + design-taste-frontend: Para escrever HTML/CSS/JSX de produção em um repositório
  • high-end-visual-design / minimalist-ui / industrial-brutalist-ui / redesign-existing-projects: Implementação CSS para direções estéticas específicas
  • /design-consultation: Construção de tokens de sistema de design do zero
  • /design-review: QA visual + ciclo de correção de páginas existentes
  • /qa / /browse: Verificação de fluxo no navegador real
• Gatilhos negativos (não roube):
  • "Coloque este design no meu projeto Next.js" → frontend-skill
  • "Audite a tipografia das páginas existentes" → /design-review
  • "Crie um conjunto completo de tokens de design" → /design-consultation
• Regra de handoff: Após o design ser finalizado para produção, entregue a referência HTML + liste suposições, tokens de design e curvas de animação, para que a equipe de frontend (ou o frontend-skill) possa implementar.

Cobertura de idioma

• Primário: pt-BR, en
• Gatilhos mistos: "Me ajuda a prototype isso", "Faz um deck", "Mocka esta página", "Explora mais algumas direções"
• Riscos de localização: "deck" = apresentação de slides, "protótipo" = prototype, "mock" = rascunho; se o usuário disser "slides", reconheça como deck

Alvos de host / portabilidade

• Primário: Claude Code CLI (cenário principal — tem sistema de arquivos, pode executar bash, usar Read/Write/Edit/Glob/Grep)
• Secundário: Codex CLI, OpenClaw (desde que tenha sistema de arquivos + shell)
• Não suportado: Ambientes de chat puro sem sistema de arquivos (não é possível entregar arquivos HTML)
• Superfície portável principal: Skill pack (SKILL.md + references + assets/starters), sem necessidade de MCP / OpenAPI
• Adaptadores de host: Nenhum; todos os plataformas compartilham o mesmo SKILL.md
• Caminho de estado / persistência: Não salve nenhuma saída do usuário dentro da pasta do skill; todos os HTMLs gerados são escritos no diretório de trabalho do usuário (geralmente uma subpasta do cwd)

<success_criteria> Quantitativo:

• Precisão de gatilho: ≥ 85% de consultas do tipo "design / mock / protótipo / apresentação" acertam consistentemente
• Chamadas de ferramenta: 8-15 para um deck típico, 15-30 para um protótipo típico (incluindo Read + Write + preview)
• Taxa de falha: console error = 0 (deve ser corrigido antes da entrega)

Qualitativo:

• O usuário vê resultados parciais cedo e pode dar feedback (não entrega tudo de uma vez)
• Cada entrega inclui pelo menos 1 observação (caveat) e 1 próximo passo
• Nomes de variantes claros; alternância suave via Tweaks; consistência visual dentro do mesmo sistema de marca </success_criteria>

Passo 0: Confirmar entradas (entender a necessidade)

• Ação: Primeiro, verifique o histórico da conversa, arquivos anexados e arquivos existentes no cwd; se ainda não for suficiente para determinar a direção chave, use AskUserQuestion (se o harness suportar) ou liste as perguntas explicitamente.
• O que perguntar: Veja references/questions.md — as categorias padrão incluem "contexto do produto e ponto de partida", "número de variantes", "preferências de Tweaks", "marca / UI kit", "preferência entre novidade e conservadorismo", "o que é mais importante: fluxo / visual / texto", "densidade de análise / texto ou imagem".
• Quando não perguntar: Quando a informação for claramente suficiente, como "transforme esta screenshot em um protótipo interativo" ou "redesenhe esta UI do repositório".
• Entrada: Necessidade do usuário + contexto conhecido
• Saída: Escopo confirmado, fidelidade, número de variantes, fonte da marca / sistema de design
• Validação: Conseguir escrever um parágrafo de "suposições de design e contexto" é suficiente

Passo 1: Explorar o contexto de design

• Ação: Se o usuário forneceu UI kit / codebase / screenshots / links, leia tudo completamente — não apenas os nomes dos arquivos.
  • Caminhos representativos: theme.ts, tokens.css, colors.ts, _variables.scss, stylesheet global, código-fonte dos componentes mencionados
  • Use Grep / Glob para encontrar tokens chave, fontes, espaçamentos, bordas arredondadas
  • Copie valores exatos do código-fonte (hex, spacing, font stack, border radius)
• Se o usuário forneceu apenas screenshots: Use Read (suporta imagens) para observar; mas Claude é melhor a reconstruir a partir de código, screenshots são apenas auxiliares.
• Se não houver nenhum contexto de design: Pare e diga ao usuário que começar do zero produzirá resultados muito genéricos; peça pelo menos sites de referência, screenshots ou autorização para "começar do zero".
• Entrada: Arquivos, screenshots, URL, conversa
• Saída: Um "relatório de observação de design" — paleta de cores, fontes, ritmo de espaçamento, vocabulário de componentes, tom do texto, padrões de sombra / cartão / layout, densidade
• Validação: Conseguir citar 3 ou mais padrões existentes a serem seguidos

Passo 2: Estabelecer a narrativa do sistema de design (pensar em voz alta)

• Ação: Antes de começar a escrever código, fale em voz alta sobre o sistema que você vai adotar:
  • Decisões de layout (quantas cores de fundo, quantos estilos de título, quais layouts)
  • Decisões de ritmo (quais slides usam imagem full-bleed, quais usam texto puro, quais colocam citações)
  • 1-2 cores de fundo principais; paleta vem da marca; se muito restrita, use oklch() para estender no mesmo matiz
  • Estratégia de fontes: se o sistema já tem, use-o; se não, defina 2-3 opções como variáveis CSS no <style> e exponha como Tweaks
• Entrada: Observação de design
• Saída: Um parágrafo de 3-8 frases de "narrativa de design", que se tornará o comentário no topo do arquivo HTML + base para decisões durante o desenvolvimento
• Validação: Após o usuário ler, ele pode dar feedback "sim, essa direção" ou "não, mude para ___"

Passo 3: Criar estrutura de pastas + copiar componentes iniciais

• Ação: Crie uma subpasta no cwd, por exemplo design/onboarding-prototype/. Se a pasta com o mesmo nome já existir e não estiver vazia: Pergunte ao usuário se deseja sobrescrever, mesclar ou renomear (por exemplo, design/onboarding-prototype-v2/) — não presuma sobrescrever, nem coloque arquivos novos em pastas antigas de outros.
• Ação: Copie apenas os starters que realmente serão usados (lista em references/starter-components.md), não despeje tudo.
• Ação: Copie também os ativos de marca / UI kit para esta pasta, não referencie caminhos externos — o trabalho deve ser executável de forma independente.
• Entrada: Narrativa de design + seleção de starter
• Saída: Uma pasta limpa e autocontida
• Validação: ls na pasta, cada arquivo tem uma razão para existir

Passo 4: Resultado parcial inicial (early preview)

• Ação: Escreva um HTML esqueleto, contendo:
  • Comentário no topo do arquivo: suas suposições, narrativa de design, próximos passos TODO
  • Blocos placeholder: imagens como blocos de cor sólida, ícones como texto, texto real ou próximo do real (não use Lorem ipsum sem contexto)
  • Pelo menos funcional
• Ação: Abra o arquivo uma vez usando o método descrito em references/verification.md (veja <tool_rules> deste SKILL)
• Ação: Diga ao usuário: "Este é o rascunho inicial; assumi ___, ___. A seguir, vou adicionar ___"
• Entrada: Pasta + narrativa
• Saída: HTML v0 que pode ser aberto, com placeholders
• Validação: O usuário vê e pode rapidamente dizer "direção certa / errada"

Passo 5: Escrever componentes React + Babel (apenas para interatividade / animação / layouts complexos)

• Ação: Se a tarefa for HTML puramente estático (a maioria das landing / wireframe / canvas), use HTML + CSS nativos; não force React.
• Ação: Se precisar de React, use as seguintes tags de script exatas (versão fixa + hash de integridade) — não altere a versão nem remova a integridade:

<script src="https://unpkg.com/[email protected]/umd/react.development.js" integrity="sha384-hD6/rw4ppMLGNu3tX5cjIb+uRZ7UkRJ6BPkLpg4hAu/6onKUg4lLsHAs9EBPT82L" crossorigin="anonymous"></script>
<script src="https://unpkg.com/[email protected]/umd/react-dom.development.js" integrity="sha384-u6aeetuaXnQ38mYT8rp6sbXaQe3NL9t+IBXmnYxwkUI2Hw4bsp2Wvmx4yRQF1uAm" crossorigin="anonymous"></script>
<script src="https://unpkg.com/@babel/[email protected]/babel.min.js" integrity="sha384-m08KidiNqLdpJqLq95G/LEi8Qvjl/xUYll3QILypMoQ65QorJ9Lvtp2RXYGBFj1y" crossorigin="anonymous"></script>

• Ação: Carregue arquivos de componente com <script type="text/babel" src="..."></script>, não adicione type="module" — quebraria.
• Regra crítica 1 — Nomeação de objetos de estilo: Objetos de estilo de escopo global devem usar nomes específicos do componente, por exemplo const terminalStyles = { ... }, const heroStyles = { ... }; É proibido escrever const styles = { ... } — com múltiplos arquivos, a colisão de nomes quebra diretamente.
• Regra crítica 2 — Escopo Babel com múltiplos arquivos: Cada <script type="text/babel"> tem escopo independente; para compartilhar componentes entre arquivos, deve-se no final do arquivo:

Object.assign(window, {
  Terminal, Line, Spacer,
  Gray, Blue, Green, Bold,
  // ... todos os componentes a serem compartilhados
});

• Regra crítica 3 — Tamanho do arquivo: Evite arquivos com mais de 1000 linhas; divida em múltiplos JSX carregados via <script> e combine no arquivo principal.
• Regra crítica 4 — scrollIntoView: Nunca use, pois quebra em webapps; use outros métodos de scroll do DOM.
• Entrada: Narrativa + esqueleto
• Saída: HTML v1 interativo
• Validação: Abra o console e verifique se não há erros

Passo 6: Adicionar variantes + Tweaks

• Ação: Forneça 3+ conjuntos de variantes, abrangendo múltiplas dimensões (layout, cor, interatividade, texto, motion) — começando pelo padrão (seguindo os padrões existentes) e gradualmente indo para o inovador (metáforas interessantes, layout, linguagem visual).
• Ação: Coloque as variantes no mesmo HTML principal no painel Tweaks, em vez de criar novos arquivos; bifurcação de arquivos só deve acontecer para "grandes revisões que precisam preservar histórico" (use v2.html).
• Ação: A especificação completa do Tweaks está em references/tweaks.md — resumo:
  • Primeiro, registre um listener de message para __activate_edit_mode / __deactivate_edit_mode
  • Depois, window.parent.postMessage({type: '__edit_mode_available'}, '*')
  • Ao alterar valores, window.parent.postMessage({type: '__edit_mode_set_keys', edits: {...}}, '*')
  • Os valores padrão são encapsulados em JSON com /*EDITMODE-BEGIN*/{...}/*EDITMODE-END*/
  • O título do painel é "Tweaks"
• Ação: Mesmo que o usuário não tenha pedido variantes, adicione 2-3 tweaks criativos por padrão (cor, fonte, texto do CTA principal) — para mostrar ao usuário mais possibilidades.
• Entrada: v1
• Saída: v2 com variantes
• Validação: Alternar Tweaks não causa crash; cada variante tem diferença visual

Passo 7: Verificação de qualidade (verification)

• Ação: Abra o arquivo HTML principal no navegador: veja references/verification.md. Prioridade:
  1. Se o ambiente de trabalho do usuário tiver /browse (gstack): use $B goto file:///<abs-path>/<name>.html + $B snapshot
  2. Caso contrário: xdg-open (Linux), open (macOS), start (Windows)
  3. Verifique principalmente se não há erros no console, layout quebrado, interações clicáveis
• Ação: Se houver erros, corrija e abra novamente até que esteja limpo.
• Ação: Só então considere a entrega concluída.
• Entrada: v2
• Saída: v2 limpo
• Validação: Console totalmente verde, visual coerente com a narrativa

Passo 8: Resumo ultra curto

• Ação: Não faça uma longa introdução do que você fez — o usuário abrirá e verá.
• Ação: Apenas responda:
  • 1-2 observações (caveats) (por exemplo: "Assumi que a cor principal da marca é #D97757; ícones são placeholders, você precisa fornecer os ativos oficiais")
  • 1-3 próximos passos (por exemplo: "Quer que eu adicione modo escuro?" "Quer que eu crie uma versão mobile?" "Posso exportar esta versão como PPTX, precisa?")
• Entrada: v2 limpo
• Saída: Mensagem de entrega ultra curta
• Validação: Mensagem ≤ 120 caracteres

<output_contract>

1. Arquivo HTML principal: Nome de arquivo semântico (Landing Page.html, Onboarding Prototype.html), pode ser aberto com duplo clique, comentário no topo com narrativa de design + suposições
2. Estrutura de pastas: design/<projeto>/ no cwd; se a pasta já existir e não estiver vazia, pergunte antes de sobrescrever / mesclar / renomear; todas as imagens / fontes / starters são copiados para dentro, sem referenciar caminhos externos
3. Variantes / versões: Pequenas mudanças via Tweaks; grandes revisões copiadas como <nome> v2.html preservando a versão anterior
4. Notas do apresentador (apenas para deck, apenas se o usuário pedir): <script type="application/json" id="speaker-notes">[...]</script>; deck_stage.js lida automaticamente com eventos de troca de slide
5. Mensagem de entrega: Observações (1-2 frases) + próximos passos (1-3), limite de 120 caracteres

Formatação: Não escreva Lorem ipsum; placeholders com texto claro ([Imagem do herói — precisa de foto real]); não desenhe SVG complexo à mão, use placeholders para ativos oficiais; não use emoji (a menos que seja da marca); texto ≥ 24px (slide 1920×1080) / ≥ 12pt (impressão) / ≥ 44px de área de toque (mobile); priorize cores da marca, use oklch() para estender no mesmo matiz quando necessário.

Informação faltando: Sem contexto → pare e pergunte; sem ativos → placeholder e marque; sem texto → use texto placeholder realista e marque.

</output_contract>

<tool_rules>

Ferramentas nativas do Claude Code (este skill usa por padrão):

• Read: Ler arquivos de referência de design, imagens, PDFs, HTML existentes
• Write: Gerar HTML / JSX / CSS
• Edit: Modificar incrementalmente arquivos existentes
• Glob / Grep: Encontrar tokens de UI kit, componentes existentes
• Bash: Copiar componentes iniciais, abrir navegador para preview, executar grep / ls
• AskUserQuestion (se o harness fornecer): Uma rodada de perguntas estruturadas, não espalhe em múltiplas rodadas
• WebFetch: Buscar conteúdo de páginas de design de referência públicas (texto puro); para referência visual, peça screenshots ao usuário
• /browse (gstack): Se o ambiente do usuário tiver instalado, use para abrir HTML em um navegador real para verificação; veja references/verification.md

Não use:

• Este skill não faz publicação remota, git push, deploy — peça ao usuário para lidar com isso
• Não instale novos pacotes npm — use versões fixas de CDN + hash de integridade
• Não simule ou recrie nenhuma UI comercial específica protegida por direitos autorais; se o usuário pedir para imitar o produto de sua empresa, é necessário que o email do usuário comprove que trabalha na empresa

Regra de aprovação (confirme antes de ações de alto risco):

• Excluir arquivos existentes (a menos que sejam claramente rascunhos acabados de gerar nesta sessão)
• Modificar significativamente arquivos de sistema de design existentes
• Copiar em lote mais de 20 arquivos

Conjunto ativo de ferramentas: Mantenha pequeno por padrão — um fluxo de design típico geralmente usa apenas Read / Write / Edit / Bash / Glob.

</tool_rules>

<default_follow_through_policy>

• Faça diretamente (baixo risco, reversível): Criar pastas, escrever HTML / JSX / CSS, copiar starters / ativos, ajustar layout / cor / fonte / curva de animação, adicionar Tweaks / variantes / placeholders, abrir navegador para preview
• Pergunte primeiro: Expandir escopo (adicionar seção / fluxo / página), copiar em lote > 20 arquivos, trocar para cor / fonte da marca especificada pelo usuário, referenciar amplamente componentes de codebase de terceiros, expandir página única para várias, sobrescrever pasta com mesmo nome
• Pare e relate: Zero contexto de design e sem autorização para "começar do zero" → pare e pergunte; se for solicitado a imitar UI comercial protegida por direitos autorais e o domínio de email não corresponder → recuse e sugira design original; problemas óbvios de acessibilidade / legais (fonte muito pequena, contraste insuficiente) → aponte primeiro e pergunte se deve corrigir

</default_follow_through_policy>

Regras críticas (obrigatórias, não podem ser violadas)

1. React + Babel devem usar versão fixa + hash de integridade (veja snippet no Passo 5). Alterar a versão ou remover a integridade quebrará.
2. const styles = {...} é proibido — variáveis com o mesmo nome em múltiplos arquivos colidem. Use const <nomeDoComponente>Styles = {...} ou inline style.
3. Para compartilhar componentes entre arquivos Babel, use Object.assign(window, {...}) — cada <script type="text/babel"> tem escopo independente.
4. Não use scrollIntoView em artefatos visualizados em iframe (Artifacts do Claude.ai) — o ambiente host pode ser perturbado. Em arquivos HTML locais, scrollIntoView funciona bem; se não tiver certeza de onde o usuário visualizará, use window.scrollTo() ou element.scrollTop para maior segurança.
5. Conteúdo de tamanho fixo (deck, motion video) deve usar escalonamento interno — use deck_stage.js (web component) diretamente, não implemente transform: scale() manualmente.
6. Arquivos com mais de 1000 linhas devem ser divididos — múltiplos JSX carregados via <script>, combinados no arquivo principal.
7. Escala base: Texto em slide 1920×1080 ≥ 24px; impressão ≥ 12pt; área de toque em mobile ≥ 44px.
8. Sem clichês de IA: Evite gradientes exagerados, emoji (a menos que seja da marca), o template "container arredondado + barra de cor à esquerda", SVG ilustrado manualmente, fontes superutilizadas como Inter / Roboto / Arial / Fraunces.
9. Sem conteúdo de enchimento: Cada elemento deve ter uma razão para existir; se uma seção parece vazia, é um problema de design — resolva com layout, não com conteúdo aleatório.
10. Rotule slides e telas: Adicione data-screen-label aos elementos que representam slides / telas ("01 Título", "02 Agenda"), indexado a partir de 1.
11. Copie ativos localmente: Não referencie caminhos externos; copie tudo para a pasta do projeto.
12. Adicione notas do apresentador apenas quando solicitado.

Sub-fluxos (operações detalhadas por tipo)

Detalhes longos estão em references/, carregue apenas quando for realmente executar a tarefa:

• Slide deck: references/decks.md
• Interactive prototype (incluindo interpretação de elementos mencionados): references/prototypes.md
• Animation / motion: references/animations.md
• Wireframe + design canvas: references/wireframes.md
• Especificação completa do Tweaks: references/tweaks.md
• Diretrizes de conteúdo / visual / layout: references/content-guideline