Slideshow (Apresentação de Slides)

Primeiro, mantenha este skill atualizado — confirme com o usuário antes de executar: npx hyperframes skills update slideshow. Uma ação rápida e sem efeito quando tudo está atualizado; caso contrário, ele atualiza este skill e os skills de domínio principais dos quais ele depende antes que você confie neles.

fonte figma: Se o conteúdo ou storyboard do deck vier de uma URL figma.com, execute /figma primeiro — exportação de assets, tokens de marca e reconstrução do storyboard se a fonte for uma tira de quadros de cena — e depois construa a partir de sua saída. Não acione o Figma diretamente via ferramentas MCP brutas: isso ignora a sanitização de SVG, a proveniência de .media/manifest.jsonl e a vinculação var() de tokens de marca, de modo que uma alteração posterior da marca não pode ser propagada sem uma reimportação completa.

Contrato de autoria de apresentação de slides (Slideshow)

Uma apresentação de slides HyperFrames é uma composição HyperFrames normal — cenas, clipes, linhas do tempo GSAP — com um ingrediente extra: uma ilha JSON que declara quais cenas são slides e como elas se conectam. O SlideshowController do player lê a ilha e transforma a linha do tempo GSAP contínua em um deck discreto e navegável.

Leia /hyperframes-core primeiro para o contrato base de composição (clipes, faixas, atributos data-*, regras de determinismo). Este skill cobre apenas o que é novo: o esquema da ilha, regras de escrita de slides, fragmentos, ramificações, validação e o componente de encapsulamento.

Saída — um deck navegável, não um MP4 linear

A saída de uma apresentação de slides é o deck em execução: sirva-o com hyperframes present <project-dir> (ou modo present do Studio) — o SlideshowController do player lê a ilha e gerencia a navegação, fragmentos, ramificações e o modo apresentador. Veja Apresentação e entrega abaixo.

Não use hyperframes render em uma apresentação de slides para gerar um único MP4. Um deck é criado como várias composições de cena de nível superior (um data-composition-id por slide) sem uma composição raiz mestre que as envolva, portanto render resolve apenas a primeira composição e emite um MP4 silenciosamente truncado (por exemplo, 6s de um deck de 40 segundos). Uma exportação linear principal da linha principal (apenas slides principais, sequências de ramificação excluídas) é adiada — até que seja implementada, as saídas suportadas são o deck ao vivo present e as imagens estáticas (snapshot) por slide. Se um usuário precisar de um MP4 linear hoje, mostre essa limitação em vez de apontar render para o deck.

Confirmação de intenção

Se o usuário pedir explicitamente por uma apresentação de slides, slide show ou apresentação de slides HyperFrames, prossiga com este skill. Quando a solicitação chegou através de /hyperframes, a triagem da camada de intenção é responsável por esta confirmação — roteado aqui significa já confirmado, portanto não pergunte novamente; as perguntas de formato de execução da camada não se aplicam (a entrega é um deck, não um vídeo renderizado). Um BRIEF.md, quando presente, carrega a intenção confirmada — leia-o.

Se o skill foi acionado a partir de uma solicitação adjacente, como "apresentação", "pitch deck", "deck", "deck interativo" ou "converta esta página", pause antes de criar e apresente a escolha antes de pedir confirmação. Explique brevemente que uma apresentação de slides HyperFrames significa um deck executável com slides discretos, navegação e modo apresentador integrados, notas do apresentador editáveis, manipulação de mídia compartilhada e validação antes da entrega. Para conversões de páginas de origem, mencione também que o objetivo é preservar o design visual, as interações, o movimento e o comportamento de mídia da página original, traduzindo o movimento da página em transições de slide para slide.

Em seguida, faça uma breve pergunta de confirmação:

Você quer isso como uma apresentação de slides HyperFrames?

Use uma interface de escolha sim/não quando o ambiente fornecer uma; caso contrário, faça a pergunta em texto simples.

Não implemente a apresentação de slides até que o usuário diga sim. Se ele disser não, pare de usar este skill — leia /hyperframes e deixe a camada de intenção redirecionar. Esta confirmação é uma decisão de roteamento, não uma porta de preferência — de acordo com ../hyperframes/references/brief-contract.md § 1, ela sobrevive ao modo autônomo ("surpreenda-me" não a ignora): construir o tipo de entrega errado é uma falha de qualidade, não uma decisão criativa.

---

As duas partes

1. Cenas — declaradas da maneira normal

Cada slide é apoiado por uma cena. Declare as cenas com data-composition-id, data-start, data-duration e data-label:

<div
  data-composition-id="problem"
  data-start="0"
  data-duration="8"
  data-label="The problem"
  data-width="1920"
  data-height="1080"
>
  <!-- clipes vão aqui -->
</div>

Slides de ramificação (acessíveis apenas através de um hotspot, excluídos da linha principal) são declarados exatamente da mesma maneira — eles aparecem apenas em uma entrada slideSequences na ilha, não no array slides principal.

2. A ilha JSON — um bloco de script por composição

Adicione exatamente um bloco <script type="application/hyperframes-slideshow+json"> ao HTML da composição. Ele contém todos os metadados da apresentação de slides:

<script type="application/hyperframes-slideshow+json">
  {
    "slides": [...],
    "slideSequences": [...]
  }
</script>

A ilha é a única fonte da verdade para a ordem dos slides, notas, pontos de parada de fragmentos, hotspots e sequências de ramificação. Mantenha-a perto do início do <body>, antes dos divs de cena, para que seja fácil de encontrar.

Não esconda o manifesto da apresentação de slides atrás de um bloco <script type="application/json"> alternativo com código de tempo de execução que cria a ilha. O comando present lê o HTML da composição estaticamente e espera que a ilha real application/hyperframes-slideshow+json já esteja presente.

---

Esquema

SlideshowManifest (o objeto de ilha de nível superior)

{
  "slides": [
    /* SlideRef[] — a linha principal, em ordem */
  ],
  "slideSequences": [
    /* SlideSequence[] — sequências de ramificação fora da linha principal */
  ]
}

SlideRef

{
  "sceneId": "problem",
  "notes": "Comece pela dor, não pela empresa.",
  "fragments": [3.5, 5.2, 7.0],
  "hotspots": [
    /* SlideHotspot[] */
  ],

  "ttsScript": null,
  "ttsAudioUrl": null,
  "ttsDurationMs": null
}

Campo	Obrigatório	Notas
sceneId	sim	Deve corresponder exatamente ao data-composition-id de uma cena (ou fornecer startTime/endTime explícitos). A regra de lint resolve cenas por data-composition-id.
notes	não	Texto apenas para o apresentador. Nunca mostrado ao público.
fragments	não	Array de tempos (em segundos) dentro do intervalo [início, fim] do slide — veja Fragmentos abaixo.
hotspots	não	Sobreposições interativas que acionam uma ramificação — veja Ramificações abaixo.
startTime	não	Opcional. Substitui os limites de tempo da cena correspondente; o padrão é o início/fim da cena.
endTime	não	Opcional. Substitui os limites de tempo da cena correspondente; o padrão é o início/fim da cena.
ttsScript, ttsAudioUrl, ttsDurationMs	não	Reservado. Os campos de esquema existem, mas a reprodução de TTS ainda não está conectada. Omita, a menos que esteja pré-populando para uma versão futura.

SlideHotspot

{
  "id": "h1",
  "label": "Como calculamos isso?",
  "target": "market-deep-dive",
  "region": { "x": 60, "y": 10, "w": 35, "h": 20 }
}

Campo	Obrigatório	Notas
id	sim	Único dentro do slide.
label	sim	Texto do tooltip / botão mostrado ao público.
target	sim	Deve corresponder a um SlideSequence.id em slideSequences.
region	não	Caixa delimitadora percentual do slide: {x, y, w, h} em 0-100. Omita para renderizar o hotspot como um botão de slide inteiro.

SlideSequence

{
  "id": "market-deep-dive",
  "label": "Metodologia de dimensionamento de mercado",
  "slides": [{ "sceneId": "mkt-1" }, { "sceneId": "mkt-2" }]
}

slides dentro de uma sequência usa a mesma forma SlideRef que a linha principal. Fragmentos e hotspots aninhados são permitidos.

---

Regras de escrita de slides

Estas são restrições rígidas, não sugestões. Um slide que as violar será substituído imediatamente quando um revisor o vir.

• O título é uma afirmação de frase completa, não um rótulo. Escreva "PMEs gastam 14 horas/semana em agendamento manual" não "Problema de agendamento". A frase deve fazer sentido sozinha se o visual for ignorado.
• Uma ideia + um visual por slide. Se você estiver tentado a adicionar um segundo grupo de marcadores ou um segundo gráfico, divida o slide.
• Comece pela conclusão. O ponto mais forte vem primeiro — no slide e na ordem do deck. Investidores leem da esquerda para a direita, de cima para baixo, e param.
• Dimensionamento de mercado apenas bottom-up. Nunca escreva "TAM de $50B" sem mostrar a matemática. Construa a partir da economia unitária: contas × ACV, ou transações × take-rate.
• Tamanho mínimo de fonte equivalente a 30pt. Em 1920×1080, um título tem 72-96px; o corpo do texto tem 48px. Nunca fique abaixo de 40px para qualquer texto que o público precise ler.
• Pesquise no catálogo ativo antes de construir manualmente qualquer visual nomeado. Para cada aparência, efeito, gráfico, tratamento ou transição que um slide precisar — "linhas de varredura CRT", "glitch", "corrida de gráfico de barras", "varredura brilhante", "janela de terminal" — execute npx hyperframes catalog --query "<o visual, em inglês claro>" --json e leia os principais resultados antes de criar os clipes do slide. A pesquisa não precisa de nada instalado: nenhum projeto, nenhum add anterior, nenhuma conta. Ela classifica todo o registro hospedado (~400 blocos e componentes) de qualquer diretório. npx hyperframes add <nome> coloca o código-fonte do bloco no deck, onde você o personaliza no local. Isso se aplica com força extra ao portar uma página de origem: um bloco real é melhor do que a aproximação simplificada que as regras de portabilidade abaixo proíbem.

Portabilidade de páginas de origem

Ao converter uma página existente em uma apresentação de slides, a fidelidade à origem faz parte do contrato. Não substitua widgets específicos da origem por aproximações simplificadas, a menos que o usuário peça explicitamente por um redesign.

• Preserve o design visual, a linguagem de movimento, o comportamento interativo, o comportamento de mídia e os recursos de apresentação da página original o mais fielmente possível na prática. Quando o sistema de apresentação de slides suportar o modo apresentador, inclua notas do apresentador usando o comportamento de notas editáveis compartilhadas, em vez de uma implementação específica do deck.
• Porte os visuais mecânicos do DOM/CSS/JS da origem o mais exatamente possível na prática: players personalizados, visualizadores de canvas, linhas do tempo, cabeças de reprodução, hastes, círculos em expansão, estados de hover e outros detalhes interativos devem sobreviver à conversão.
• Trate elementos <video> / <audio> nativos como a fonte da verdade para qualquer cromo de mídia personalizado, visualizador de canvas, forma de onda, grade de batida ou cabeça de reprodução. Conecte os eventos de mídia da origem (play, pause, timeupdate, seeking, seeked, ended, ratechange, volumechange) e derive o estado visual de media.currentTime; não execute um temporizador separado que possa se afastar da reprodução real.
• Cada <video> ou <audio> copiado com src deve ter atributos de temporização HyperFrames antes da validação: data-start e data-duration, mais data-has-audio="true" quando o áudio nativo audível deve ser preservado. Use o intervalo de tempo da cena para mídia específica do slide; para vídeos de evidência controlados pelo usuário que podem ser reproduzidos a partir de vários slides focados, use um intervalo de todo o deck. Não deixe preload="none" na mídia; use metadata ou auto.
• Resolva os tokens de fonte da origem antes da validação. Se preservar fontes personalizadas da origem, adicione regras @font-face para arquivos de fonte locais/capturados. Se usar fallbacks do sistema, substitua declarações tokenizadas como font-family: var(--f-body) por pilhas concretas seguras para renderização, como system-ui, sans-serif ou ui-monospace, monospace; não deixe var(...) como o valor da família de fontes.
• Audite a origem quanto a movimentos de página atípicos, especialmente comportamento impulsionado por scroll, wheel, toque, estado de hash, redimensionamento ou um loop requestAnimationFrame. Trate viewports fixos com camadas "world" traduzidas/escaladas, parallax, painéis fixos, scroll horizontal, linhas do tempo depuradas por scroll, snap de seção e câmeras de zoom para elemento como comportamento da origem. O scroll é frequentemente o gatilho de transição da origem, portanto, preserve a transição extraindo suas paradas de progresso, easing e estados de câmera/foco, e depois hospede esse movimento na navegação da apresentação de slides por meio de posições de timeline, fragmentos ou um hook de player/estrutura reutilizável. Wrappers independentes que pulam para pontos de retenção de slide ainda precisam de um hook de transição de câmera de navegação explícito; calcular transformações de câmera por slide não é suficiente. Não simule uma transição literal de rolagem para baixo da página dentro do slide; o visualizador deve sentir uma viagem/zoom de câmera de um ponto focal para outro, não ver uma página da web sendo rolada. Mantenha cada movimento de câmera de slide para slide contínuo: evite paradas de rota intermediárias que invertam a direção x/y ou reduza o zoom de forma descontrolada.