Web Slides
Transforme um conjunto de materiais, esboços ou tópicos em uma apresentação de slides HTML com estética cinematográfica, pronta para ser exibida ao vivo. Resultado = projeto Vite + React + TS, avançando com clique / setas, cada etapa ocupando a tela inteira. Pressione P para abrir uma janela separada do apresentador com as notas de locução (visualização em tempo real + cronômetro, duas janelas sincronizadas; compartilhe apenas a janela principal do slide na projeção para ocultar do público). Pressione N para uma sobreposição de notas de ensaio.
Diferença para [web-video-presentation]: Aquela skill cria "páginas que se passam por vídeos" — com roteiro de locução, áudio sintetizado e gravação de tela. Esta skill é apenas para slides ao vivo: sem roteiro de locução, sem áudio, sem captura de tela; o texto de cada etapa se torna notas do apresentador (presenter notes), servindo como teleprompter para o orador, sem nunca aparecer na tela. As demais metodologias visuais, sistema de temas e princípios de revelação progressiva são totalmente preservados.
Cenários de Uso
- "Tenho alguns materiais / um esboço, me ajude a criar slides / uma apresentação"
- Palestra técnica / keynote / demonstração de produto / pitch deck / material didático
- Retrospectiva de projeto para entrevista (project retro) — apresente ao vivo com slides, pressione P para abrir a janela do apresentador e ver as anotações
- Deseja um formato widescreen 16:9, letras grandes, espaços em branco e animações por tela: um "PPT dinâmico que não parece PPT"
- Transformar um artigo / um conjunto de anotações em uma explicação interativa passo a passo
Esta skill é centrada em metodologia + fluxo de colaboração. O template do scaffold fornece tokens e primitivas, mas cada decisão estética (paleta de cores, tipografia, estilo das animações) deve ser redesenhada para o seu tema — não copie modelos.
Dois Perfis de Densidade: Estilo Vídeo / Estilo Deck de Apresentação
O mesmo motor pode executar dois ritmos diferentes. Defina um na Phase 1 (escreva no topo do outline.md, confirme com o usuário no Checkpoint Plan):
| 🎬 Estilo Vídeo (padrão / esparso) | 🎤 Estilo Deck de Apresentação (páginas limitadas / alta densidade) | |
|---|---|---|
| Cenário | Gravação com locução, fala contínua, muitos compassos | Apresentação ao vivo / projetada, páginas limitadas, fala em torno de uma página (comum em retrospectivas de entrevista) |
| Um slide | = um step (ocupa a tela inteira) | = um capítulo (uma página estável e densa) |
| Semântica do step | Avançar para a próxima ideia (mudar de cena) | Construir progressivamente no mesmo slide (elementos aparecem gradualmente, sem mudar de cena) |
| Informação por tela | 1 hero + 1~3 elementos + bastante espaço em branco | Imagem / tabela / diagrama + alguns pontos + dados podem coexistir na tela |
| Escala | Muitos capítulos × poucos steps | Menos capítulos (≈ número desejado de páginas) × 2~5 construções por capítulo |
| Tema | Qualquer um | Preferir temas estruturais / editoriais (newsroom / monochrome-print / blueprint / swiss-ikb / vintage-editorial) |
Nenhum dos dois altera o motor (capítulo/step, palco 16:9, tokens, MaskReveal são universais). A diferença está apenas em como o capítulo é escrito. O modo deck flexibiliza "uma ideia por tela / muito espaço em branco / hero total", mas "evitar aparência de IA" + tokens + hierarquia real + deve ter demonstração visual + fonte dupla continuam — essa é a base para "não ficar feio". Para detalhes de escrita de cada capítulo, veja CHAPTER-CRAFT.md na seção "Dois Perfis de Densidade".
Em dúvida → 🎬 Estilo Vídeo.
Visão Geral do Fluxo de Trabalho
Phase 1 Planejamento de Conteúdo
1.1 Identificar a entrada do usuário
1.2 Produzir outline.md
(divisão em capítulos + conteúdo de cada step + notas opcionais + pool de informações)
▼
[Checkpoint Plan] ← Deve parar. Alinhar 4 coisas de uma vez:
outline / tema / materiais / modo de desenvolvimento
▼
Phase 2 Desenvolvimento Web
2.1 Scaffold (com o tema selecionado)
2.2 Capítulo 1 = thread principal + versão completa (âncora obrigatória)
▼
[Ponto duro] Usuário valida o Capítulo 1 ← Incontornável
▼
2.3 Capítulos 2~N (conforme modo selecionado: A capítulo por capítulo / B sequencial / C paralelo)
▼
[Checkpoint Done] ← Slides prontos, servidor dev rodando
▼
Phase 3 Apresentação / Exportação
Não há fases de "síntese de áudio" e "gravação de tela" — são slides, não vídeos.
Convenção de diretório de trabalho (o agente cria / edita no diretório atual do usuário):
my-slides/
├── material.md # Preservar quando o usuário fornece material bruto — não deletar! Fonte de informação visual durante o desenvolvimento
├── outline.md # Obrigatório: plano de desenvolvimento (divisão em capítulos + conteúdo de cada step + pool de informações + notas opcionais)
└── presentation/ # Projeto Vite + React + TS gerado pelo scaffold
└── src/chapters/<NN>-<id>/
├── <Chapter>.tsx # Implementação visual
├── <Chapter>.css
└── notes.ts # ★ Única fonte da verdade para número de steps + notas do apresentador
Crucial:
notes.tsé a única fonte da verdade para o número de steps. O maior N + 1 emif (step === N)no<Chapter>.tsxdeve ser igual anotes.length. Isso garante que o código do capítulo, a barra de progresso e o stepper nunca fiquem dessincronizados. O conteúdo das notas (strings no array) alimenta apenas a janela do apresentador (tecla P) e a sobreposição de notas (tecla N), nunca aparece na tela do slide, pode ficar vazio"".
Protocolo de Autoverificação Obrigatório (Durante Toda a Skill)
Para cada um dos dois artefatos abaixo, após a conclusão, deve-se executar: autoverificação → correção → só então relatar / avançar:
| Artefato | Origem da Lista de Verificação |
|---|---|
outline.md | Autoverificação de OUTLINE-FORMAT.md |
| Implementação de um capítulo concluída | Autoverificação de conclusão em CHAPTER-CRAFT.md |
Modo de execução (em ordem decrescente de capacidade, priorize a forma mais isolada):
- Agent Teams (melhor): Inicie um agente revisor independente, forneça a ele "caminho do arquivo de saída + lista de verificação correspondente + contexto chave", peça para verificar item por item e relatar conclusões estritamente (quais itens passaram / quais falharam + evidências + sugestões de reescrita).
- subAgent (segunda melhor): Se não tiver capacidade de Teams, mas puder iniciar subagentes, use um subagente para seguir o mesmo fluxo.
- Autoverificação (último recurso): Se o agente atual não tiver nenhuma das capacidades acima, faça a verificação estritamente item por item — não é permitido apenas dar uma olhada e liberar.
Regra de ferro: Após obter as conclusões, primeiro corrija os itens com falha na saída e só então relate ao usuário "concluído + conclusão da verificação + o que foi alterado". Relatar diretamente as conclusões originais sem corrigir = violação de regra.
Guia de Leitura de Arquivos por Fase
Diferentes fases exigem a leitura de diferentes arquivos. Em sessões longas, o agente tende a esquecer os princípios, especialmente na Phase 2.4 "Implementar um capítulo" que se repete N vezes — a cada vez, deve-se revisitar as restrições principais.
| Fase | Leitura Obrigatória (toda vez) | Leitura única / Consulta sob demanda |
|---|---|---|
| Phase 1.1-1.2 Planejamento de Conteúdo | references/OUTLINE-FORMAT.md + material.md (material bruto do usuário, se houver) | —— |
| Checkpoint Plan Escolher Tema | —— | themes/*/theme.json (ler todos dinamicamente, listar + recomendação bestFor + descriptionZh); references/THEMES.md (quando o usuário quiser entender o sistema de temas) |
| Phase 2.1 Scaffold | —— | SKILL.md desta seção, ler uma vez |
| Phase 2.4 Implementar um Capítulo (×N vezes, chamado por 2.2 / 2.3) | references/CHAPTER-CRAFT.md como ponto de entrada único — requisitos de demonstração visual / revelação progressiva / curadoria de conteúdo / fonte dupla (outline+material) / estética de apresentação / evitar aparência de IA / restrições mínimas de código (incluindo restrição obrigatória de notes.ts) / referência de duração / autoverificação de conclusão + themes/<id>/theme.json do tema atual + parágrafo do outline.md do capítulo atual + parágrafo correspondente no material.md para este capítulo + lista de materiais | references/EXAMPLES/ (para estrutura, não para copiar modelo); references/THEMES.md para o contrato completo de tokens |
| Phase 3 Apresentação / Exportação | references/PRESENTING.md (tela cheia, navegação por teclado, tecla N para ver notas, exportar PDF / captura de tela) | —— |
| Selecionar / Criar / Personalizar Tema | —— | references/THEMES.md |
Ao escrever um capítulo, leia apenas um arquivo:
CHAPTER-CRAFT.md. Os dez princípios / self-prompting inicial / árvore de decisão / antipadrões de aparência de IA / autoverificação de conclusão — tudo está consolidado neste único ponto de entrada.EXAMPLES/não é leitura obrigatória — primeiro, projete livremente com base no conteúdo; só consulte se estiver travado (use como referência de "forma", não copie).
Phase 1 — Planejamento de Conteúdo
1.1 Identificar a Entrada do Usuário
| O que o usuário fornece | O que fazer |
|---|---|
| Material bruto (artigo / anotações / uma lista de tópicos / dados) | Produzir outline.md (1.2), preservar o material original como material.md, passar pelo Checkpoint Plan |
| Um esboço / roteiro já escrito | Organizar no formato outline.md (1.2), passar pelo Checkpoint Plan |
| Nada, apenas "me ajude a criar slides sobre o tema X" | Pergunte de volta: primeiro, forneça um material ou tópicos. A skill não substitui a ideação do usuário |
1.2 Produzir outline.md
Siga as regras de references/OUTLINE-FORMAT.md: dividir em capítulos → dividir em steps → extrair pool de informações para o primeiro parágrafo de cada capítulo → para cada step, escrever o conteúdo da tela (+ dica opcional de nota do apresentador).
Primeiro, defina o perfil de densidade (🎬 Estilo Vídeo / 🎤 Estilo Deck, veja a seção "Dois Perfis de Densidade" acima) — ele decide diretamente como os capítulos são divididos: no modo deck, número de capítulos ≈ número desejado de páginas, com 2~5 construções por capítulo.
Preserve o material.md e não o delete — ele é a fonte de detalhes para escrever o pool de informações no outline e o conteúdo visual na implementação dos capítulos (princípio da fonte dupla).
Limites do outline (crucial):
| O outline deve conter | O outline não deve conter |
|---|---|
| Divisão em capítulos / número de steps por capítulo / duração estimada | Tipos específicos de animação (blur clear / wipe / mola) |
| Conteúdo da tela por step (hero / dados / slogan / itens de lista) | Meios de implementação CSS (filter / SVG / clip-path) |
| Pool de informações por capítulo: números / citações / casos / tags extraídos do material | Valores numéricos de duração / micro-ritmo |
| Dica de nota do apresentador por step (opcional: o que você planeja dizer neste step) | Micro-ritmos como movimento contínuo / deslocamento de pico |
| Prefixo de relação entre steps ("contraste", "lista progressiva", "frase de efeito", etc.) (dica opcional) | —— |
Motivo para o outline não especificar animações: Especificar animações degrada o agente do capítulo a um mero tradutor; deixar em branco permite que o agente do capítulo, ao iniciar cada step, projete livremente com base na "árvore de decisão orientada por conteúdo" do
CHAPTER-CRAFT.md, gerando um senso visual genuíno.
Após salvar, deve-se executar a autoverificação antes de prosseguir para o Checkpoint Plan: Siga o "Protocolo de Autoverificação Obrigatório" acima para outline.md (priorize Agent Teams → subAgent → autoverificação), corrija com base nas conclusões e então prossiga.
Checkpoint Plan — Alinhar 4 Coisas de Uma Vez (Ponto Duro)
Após escrever o outline.md, é obrigatório parar. O usuário confirma 4 coisas simultaneamente neste ponto.
Trabalho Preparatório do Agente neste Momento
- Leia todos os
themes/*/theme.jsonpara obternameZh/descriptionZh/bestFor/mood— não codifique a lista diretamente - Com base no tipo de conteúdo / palavras-chave / tom do outline, proativamente selecione 2~3 temas mais adequados como recomendação (combinando com o campo
bestFor) - Revise a seção "Lista de Materiais" no final do
outline.md
Modelo de Resumo (esqueleto, o agente preenche conforme o caso)
Plano de conteúdo concluído. Arquivos gerados:
📄 material.md {preservado se o usuário forneceu material bruto}
📄 outline.md {N} capítulos / {M} steps + pool de informações por capítulo + lista de materiais no final
Visão geral dos capítulos:
1. <id> <Título do Capítulo> <S> steps ~<T>s
2. ...
A seguir, alinhar 4 coisas de uma vez:
1. O plano de desenvolvimento (outline.md) precisa de ajustes? Foco em:
- O perfil de densidade está correto? (🎬 Estilo Vídeo: muitos steps esparsos / 🎤 Estilo Deck: páginas limitadas, alta densidade)
- A divisão em capítulos / número de steps é razoável? (~5~12 steps por capítulo é uma faixa comum)
- O conteúdo da tela por step está claro?
- O "pool de informações" no primeiro parágrafo de cada capítulo tem detalhes materiais suficientes para sustentar o visual?
- A lista de materiais no final está completa?
2. Qual tema escolher? Minha recomendação:
★ <Recomendação 1: nameZh (id)> — porque <bestFor corresponde>; <resumo descriptionZh>
★ <Recomendação 2 / Recomendação 3>
Outras opções: <temas restantes, nameZh + uma frase>
Também posso criar um novo tema para você (veja references/THEMES.md para detalhes).
3. Como preparar os materiais visuais? Dê uma olhada geral nas imagens necessárias para esta apresentação: <lista aproximada>
a) Eu seleciono a partir de <caminho do material existente> b) Você fornece c) Tudo placeholder
4. Qual modo de desenvolvimento escolher?
**O Capítulo 1, independentemente do modo, deve ser feito na thread principal com validação do usuário** (âncora obrigatória).
A diferença está nos Capítulos 2 em diante:
A) Padrão · Confirmação capítulo por capítulo (recomendado)
Pausar e validar após cada capítulo → risco controlado / ritmo mais estável
B) Desenvolvimento sequencial após o Capítulo 1 (sem paralelismo)
Capítulos 2~N feitos sequencialmente na thread principal, validação unificada no final → velocidade média / adequado para agentes sem suporte a paralelismo
C) Desenvolvimento paralelo após o Capítulo 1 (subagent)
Capítulos 2~N feitos em paralelo com subagentes → mais rápido / usuário controla o número de paralelismos (quantos capítulos por vez)
⚠️ Pode haver diferenças de estilo entre capítulos (esperado, pois o tema fornece a base de restrições)
Após receber o feedback:
- Se o outline precisar de alterações: edite o arquivo diretamente, após editar pingue uma vez (ou descreva oralmente para o agente alterar)
- O tema deve ser definido explicitamente para entrar na Phase 2. Se o usuário disser "você escolhe o tema para mim" → pegue a primeira recomendação, informe ao usuário o que você escolheu e por quê, dando oportunidade de desistir
- Modo selecionado → entrar na Phase 2
Phase 2 — Desenvolvimento Web
2.1 Scaffold
bash <caminho-para-web-slides>/scripts/scaffold.sh \
./presentation \
--theme=<id do tema selecionado pelo usuário>
bash <caminho-para-web-slides>/scripts/scaffold.sh --list-themes
Tema personalizado → Primeiro, siga o fluxo de "Criação de Novo Tema" em
references/THEMES.mdpara criar umthemes/<meu-tema>/, depois use--theme=<meu-tema>.
O scaffold vem com uma demo 01-example. Delete-a antes de escrever o conteúdo real do primeiro capítulo:
rm -rf presentation/src/chapters/01-example
E remova o import e o item do array do capítulo example em presentation/src/registry/chapters.ts.
2.2 Capítulo 1 — Thread Principal + Validação Obrigatória
Essencial: Capítulo 1 = versão completa de uma vez (ritmo + visual + materiais reais completos). Não existe conceito de "versão esqueleto" — o primeiro capítulo deve ser um modelo que o usuário possa validar diretamente.
Por que o Capítulo 1 deve ser na thread principal:
- É a primeira aplicação prática das diretrizes de
CHAPTER-CRAFT.mdno tema atual + assunto atual - Se houver pontos cegos nas diretrizes / tokens de cor / fonte insuficientes, o Capítulo 1 certamente os exporá — neste momento, com feedback humano, é possível ajustar as diretrizes / tema, o custo de corrigir cedo é o mais baixo
- Capítulos subsequentes (sejam sequenciais ou paralelos) devem consultar o padrão de código do Capítulo 1, portanto o Capítulo 1 = âncora de estilo do projeto atual
Após concluir o Capítulo 1, é obrigatório parar e aguardar a validação do usuário:
Capítulo 1 <id> concluído. Servidor dev rodando em localhost:5174.
Foco da validação:
□ O visual está adequado? Corresponde às expectativas do tema <nameZh>?
□ O ritmo está bom? Algum step muito rápido / lento / informação muito superficial?
□ As animações orientadas por conteúdo estão adequadas? Ou há steps com animações de entrada sem sentido?
□ Princípio da fonte dupla: A tela tem detalhes que "as notas não mencionam, mas o material poderia fornecer"?
□ Verificação anti-aparência de IA: Há gradientes roxos / bordas arredondadas coloridas / ilustrações falsas / emojis?
□ Pressione N para ver as notas do apresentador. A leitura é fluida?
Me informe os problemas que ajusto pontualmente. Quando estiver OK, me diga "continuar" e seguirei para o Capítulo 2 em diante, conforme o modo selecionado.
2.3 Capítulos 2~N — Conforme Modo Selecionado
Regras comuns a todos os modos: Cada capítulo é desenvolvido independentemente conforme CHAPTER-CRAFT.md. O estilo não precisa ser rigorosamente idêntico entre capítulos — as cores / tokens de fonte do tema garantem a unidade visual; animações / ritmo / demonstração visual são de livre criação do capítulo, conforme design esperado.
Modo A · Padrão · Confirmação Capítulo por Capítulo
Capítulo 2 concluído → pausar para validação → OK → Capítulo 3 → pausar → ... → Capítulo N. Validação independente por capítulo, problemas corrigidos a qualquer momento, menor risco, ritmo mais estável. Se o usuário não especificar um modo, este é o padrão.
Modo B · Desenvolvimento Sequencial Após o Capítulo 1
Capítulo 2 → Capítulo 3 → ... → Capítulo N feitos sequencialmente na thread principal, validação unificada no final. Velocidade média, adequado para ambientes onde o agente não suporta tarefas paralelas.
Modo C · Desenvolvimento Paralelo Após o Capítulo 1 (subagent)
Use subagentes para fazer os Capítulos 2~N em paralelo, com o número máximo de paralelismos controlado pelo usuário ("4 capítulos de uma vez" / "2 capítulos de uma vez"). Mais rápido, mas pode haver diferenças de estilo entre capítulos — isso é esperado, porque:
- Cada subagente não vê a saída dos outros, não podendo alinhar mecanicamente
- O código dos capítulos é fisicamente separado (cada capítulo tem sua própria pasta / prefixo CSS), não se interferem mutuamente
- Os tokens do tema garantem a unidade visual (cores / fontes / números hero / cartões / linhas de separação / decoração), o estilo não foge do controle
- Estilo inconsistente = a respiração natural do trabalho manual (múltiplas vozes / múltiplas perspectivas)
O prompt do subagente paralelo deve conter:
- O parágrafo do outline do capítulo atual (com o pool de informações)
- O caminho para
references/CHAPTER-CRAFT.md(leitura única obrigatória) - O
descriptionZh/mood/bestFordotheme.jsondo tema atual - O código do Capítulo 1 como referência de "estilo de código" (não como "objeto de cópia visual")
- Regra rígida: Cada capítulo tem prefixo CSS independente (
.cd-/.mg-/.pm-/ ...); não modificarchapters.ts; cada capítulo deve ternotes.ts(comprimento = número de steps); ao concluir, executenpx tsc --noEmit
Importante: Independentemente do modo escolhido, o usuário pode alternar de modo a qualquer momento.
2.4 Implementar um Capítulo (Obrigatório para Cada Capítulo)
Consulte references/CHAPTER-CRAFT.md para orientações detalhadas — ponto de entrada único de leitura obrigatória, cobrindo: requisitos de demonstração visual / revelação progressiva / curadoria de conteúdo / princípio da fonte dupla / estética básica de apresentação visual / anti-aparência de IA / linhas vermelhas de código / autoverificação de conclusão.
Pontos essenciais (detalhados em CHAPTER-CRAFT.md):
- Cada capítulo deve ter uma demonstração visual com CSS / SVG / Canvas / JS, capítulos puramente textuais são proibidos
- Revelação progressiva: Listas devem ser 1 item = 1 step, proibido mostrar tudo de uma vez
- Princípio da fonte dupla: O ritmo segue o outline (a ordem não pode ser alterada), os detalhes são extraídos do material original (pool de informações + parágrafo do material deste capítulo)
- Cada capítulo deve ter
notes.ts: comprimento = número de steps (única fonte da verdade), o conteúdo são notas do apresentador (pode ser vazio""), nunca aparece na tela - Autoverificação de conclusão item por item: se não atender, volte e corrija — siga o "Protocolo de Autoverificação Obrigatório", corrija e só então relate a entrega deste capítulo ao usuário
2.5 Após Grandes Alterações, Atualizar STORAGE_KEY
Após alterar chapters.ts (adicionar / deletar / reordenar capítulos, ou alterar o comprimento de notes.ts de algum capítulo), atualize o STORAGE_KEY em presentation/src/hooks/useStepper.ts (ex.: web-slides-cursor-v1 → v2), para evitar que o cursor persistido aponte para um step que não existe mais.
Phase 3 — Apresentação / Exportação
Consulte references/PRESENTING.md para o fluxo detalhado. Pontos principais:
- Ao vivo:
npm run dev→ tela cheia no navegador (F11) → clique / setas para avançar. - Navegação por teclado:
← →/ espaço para avançar;Home/Endpara ir ao início / fim; teclas numéricas1-9para pular para um capítulo; teclaPabre a janela do apresentador (janela independente: notas de locução + pré-visualização em tempo real + cronômetro, duas janelas sincronizadas); teclaNabre / fecha a sobreposição de notas (sobreposta na janela atual, apenas para ensaio — ⚠️ será projetada junto). - Postura correta para projeção sem mostrar as notas: Pressione
Ppara abrir a janela do apresentador → no software de reunião, selecione "Compartilhar uma janela / guia" e escolha a janela principal do slide (não "Compartilhar tela inteira") → a janela do apresentador é visível apenas para você, a navegação por slides sincroniza as duas janelas, mesmo com um único monitor. - Distribuição offline / projeção estável:
npm run build→npm run preview, ou implante a pastadist/. - Exportação (opcional): Capture gradualmente como PNG ou use a função "Imprimir como PDF" do navegador, step a step.
Ao final da Phase 2, informe proativamente ao usuário: os slides estão prontos, o servidor dev está rodando em localhost:5174, pode apresentar ao vivo / projetar; pressione P para abrir a janela do apresentador e ver as notas de locução (ao projetar, compartilhe apenas a janela principal do slide; o público não verá as notas). Pressione N para a sobreposição de notas de ensaio (que será projetada).
Dez Princípios (Lista de Uma Frase)
Consulte a seção correspondente em references/CHAPTER-CRAFT.md para a expansão completa — consulte lá ao escrever capítulos. Abaixo está apenas um índice.
| # | Princípio | Uma Frase |
|---|---|---|
| 1 | Palco fixo 16:9 | Conteúdo 1920×1080 + transform scale, sem responsividade |
| 2 | Contador de step global | Capítulo é função pura do step, sem temporizadores |
| 3 | Cada step ocupa a tela inteira | if (step === N) return <FullScene /> |
| 4 | Compasso lógico = step | Um compasso = um step = uma ideia focada |
| 5 | Controles de canto ocultos | Barra de progresso com opacity 0 por padrão; notas ocultas por padrão (ativadas com N) |
| 6 | Palco sem cromado | Sem header / footer / número de página / barra de marca |
| 7 | Animação orientada por conteúdo | Primeiro encontre a ação intrínseca; só então use animação de entrada como fallback; movimento contínuo com moderação |
| 8 | Revelação progressiva de múltiplos pontos | 1 item = 1 step, proibido mostrar N itens de uma vez com stagger |
| 9 | Mesmo tema em toda a apresentação | Não mudar a cor de fundo entre capítulos; cores / fontes via token, outras escalas livres por capítulo |
| 10 | Princípio da fonte dupla | Outline define o ritmo, material define a densidade visual (materializada no pool de informações) |
🎤 No modo Deck, os princípios 3 "cada step ocupa a tela inteira" / 8 "1 item = 1 step" são flexibilizados para: uma página = um capítulo, step = construção progressiva na mesma página (elementos aparecem gradualmente, permanecendo na tela); os demais princípios permanecem inalterados. Veja a seção "Dois Perfis de Densidade" acima.
Consulta Rápida de Feedback Comum do Usuário
Ao receber feedback, primeiro identifique em qual camada está (ritmo / visual / conteúdo / código), depois altere o menor recorte possível, não refaça o capítulo inteiro:
- Ritmo: Muito rápido / lento / informação superficial → Dividir / mesclar steps (altere simultaneamente o comprimento de
notes.ts+if (step===N)no capítulo) - Visual: Estilo não condiz / tem aparência de IA → Volte a CHAPTER-CRAFT.md seção "Evitar Aparência de IA" + "Estética Básica de Apresentação"
- Conteúdo: Tela muito vazia / detalhes insuficientes → Volte ao pool de informações + parágrafo do
materialdeste capítulo (princípio da fonte dupla) - Código: Erro / token não funciona → Volte a CHAPTER-CRAFT.md seção "Restrições Mínimas de Código"
Recursos Relacionados
Marcado por "quando ler" para evitar ler tudo de uma vez:
| Arquivo | Quando Ler | Conteúdo |
|---|---|---|
references/OUTLINE-FORMAT.md | Leitura obrigatória na Phase 1.2 | Especificação dos campos do outline.md, convenções de nomenclatura, divisão em capítulos, pool de informações, notas por step |
references/CHAPTER-CRAFT.md | Ponto de entrada único de leitura obrigatória para cada capítulo na Phase 2.4 | Requisitos de demonstração visual / revelação progressiva / curadoria de conteúdo / fonte dupla (outline+material) / estética de apresentação / evitar aparência de IA / restrições mínimas de código (incluindo notes.ts) / referência de duração / autoverificação de conclusão |
references/EXAMPLES/ | Opcional — para ver a estrutura | Exemplos de estrutura de capítulos (hook / list-reveal / case-tech-review); não são modelos para copiar |
references/THEMES.md | Ao selecionar / criar / personalizar temas | Contrato completo de tokens + lista de temas integrados + fluxo de criação |
references/PRESENTING.md | Ler apenas na Phase 3 | Tela cheia, navegação por teclado, tecla N para ver notas, exportar PDF / captura de tela |
themes/ | Consultar no Checkpoint Plan / Phase 1.2 | Temas integrados (cada um com theme.json + tokens.css) |
scripts/scaffold.sh | Executar uma vez na Phase 2.1 | Scaffold do projeto com um comando |
Esta skill foi adaptada de
web-video-presentation(autor ConardLi) — removendo locução / áudio / captura de tela, mantendo toda a metodologia visual e o sistema de temas, focada exclusivamente em apresentações de slides ao vivo.