Mapa da trilha
Conteúdo detalhado
🎯 Demonstrativo vs Explicativo
A skill video-demonstrativo MOSTRA um app real sendo usado — não explica um conceito com motion graphics. Aqui você entende o que é um walkthrough, quando usá-lo e o que a skill entrega.
Um walkthrough é um vídeo que percorre uma aplicação web passo a passo, mostrando telas reais do app sendo usado — clicar, preencher, gerar, ver o resultado.
É o formato que demonstra como algo funciona na prática, sem o usuário precisar abrir o app sozinho.
App real, passo a passo, tela por tela, narrado.
video-explicativo explica um conceito com motion graphics (cenas animadas). video-demonstrativo mostra um app real navegado de verdade.
Escolher a skill errada custa tempo. Conceito abstrato → explicativo; ferramenta concreta → demonstrativo.
Mostrar vs explicar; tela real vs motion graphics.
Se existe uma tela para mostrar (um app, um localhost, uma URL), é demonstrativo. Se é uma ideia sem interface, é explicativo.
Um critério único elimina a dúvida e direciona ao fluxo certo logo no começo.
"Tem tela?" = demonstrativo; "É conceito?" = explicativo.
Onboarding de produto, tutorial de uma feature nova, vídeo de lançamento e material de suporte são os usos naturais do walkthrough.
Reconhecer o caso de uso ajuda a definir o roteiro de passos certo.
Onboarding, feature, lançamento, suporte.
Os screenshots reais entram numa moldura de navegador (barra + URL), com um cursor animado que clica nos controles, zoom no resultado e narração TTS.
São esses quatro elementos que transformam prints estáticos num vídeo que parece gravação de tela profissional.
Moldura de navegador, cursor, destaque/zoom, narração.
A saída é um MP4 em 16:9 (telas de app são landscape), com narração em PT-BR e a CTA do AutomationsAI na cena final.
Saber o formato natural evita pedir 9:16 (que exigiria recorte) e alinha a expectativa.
16:9, MP4, narrado, CTA final.
O ponto de partida é simplesmente o link do app — uma URL pública ou um localhost:8000. O app precisa estar no ar para a captura navegá-lo.
Entender que a entrada é o link (e não um arquivo de roteiro) muda como você prepara o trabalho.
Link do app, localhost, app no ar.
🧠 Capturar antes, animar depois
O princípio que rege toda a skill. O render do HyperFrames é determinístico — sem rede no momento de renderizar. Por isso capturam-se screenshots reais antes, e o viewport fixo da captura vira o espaço de coordenadas do cursor.
O HyperFrames renderiza o HTML em frames de forma determinística: nada de fetch ou requisições de rede durante a renderização.
É a restrição técnica de onde nasce todo o resto do princípio.
Determinístico, sem rede, frame a frame.
Como o render não acessa a rede, jamais se carrega o app ao vivo dentro do vídeo (nem em iframe) — seria inconsistente e quebraria.
Evita a tentação errada de "embedar o site" e direciona para a captura.
Sem live, sem iframe do app, só imagem.
Antes de montar o vídeo, navega-se o app de verdade e tira-se um screenshot real por estado (tela inicial, depois de preencher, depois do resultado…).
São esses prints que vão para dentro da moldura — a base visual de tudo.
1 shot por estado, antes do render, telas reais.
O viewport fixo usado na captura (ex.: 1280×800) vira o sistema de coordenadas em que tudo é posicionado depois.
Se o viewport mudar entre o shot e a medição da caixa, o cursor erra o alvo.
Viewport fixo, mesmo tamanho, ≤ ~1280 de largura.
A posição de cada elemento-alvo vem de getBoundingClientRect — coordenadas relativas ao viewport, não "no olho".
É a caixa real que faz o cursor cair exato no controle, dando o ar profissional.
getBoundingClientRect, viewport-relative, caixa real.
O cursor anima mirando o centro de cada bounding box. Para acertar, o screenshot e a caixa têm que vir do mesmo viewport e mesmo scroll.
A consistência shot↔coordenada é o que mantém o cursor sempre alinhado com o que aparece na tela.
Cursor mira a box, mesmo viewport, mesmo scroll.
🧰 A stack sem API key
Três peças locais fazem tudo: agent-browser (Playwright) para capturar, HyperFrames (HTML→MP4) para renderizar e Kokoro TTS para narrar. Nenhuma chave de API — tudo roda na sua máquina.
O agent-browser dirige um navegador via Playwright: abre a URL, navega o app, executa ações e tira os screenshots reais.
É a ferramenta que produz a matéria-prima do vídeo (shots + bounding boxes).
Playwright, navegação automatizada, screenshots.
O HyperFrames converte uma página HTML animada em MP4, usando Chrome headless para gerar frames e FFmpeg para montar o vídeo.
É o motor de saída — entender que é HTML→MP4 explica por que o render é determinístico.
HTML→MP4, Chrome headless, FFmpeg.
O Kokoro gera a narração em PT-BR localmente (voz pf_dora, --speed 0.98) — um WAV por passo, sem serviço externo.
É a fonte do áudio; o gerador mede esses WAVs para sincronizar o timing.
TTS local, pf_dora, PT-BR, WAV por passo.
As três peças rodam localmente — captura, render e narração não dependem de nenhum serviço pago nem chave de API.
Significa custo zero por vídeo e nenhum dado saindo da sua máquina.
Local, sem API, custo zero, privado.
Há três jeitos: descompactar o .zip em ~/.claude/skills/, copiar a pasta video-demonstrativo/, ou criar um symlink (para desenvolver).
Como skill é só uma pasta, instalar é copiar/colar — sem instalador.
unzip, copiar pasta, symlink.
~/.claude/skills/ torna a skill global (todo projeto); .claude/skills/ no repositório a restringe àquele projeto.
Decidir o escopo certo evita duplicar a skill ou não encontrá-la.
Global, projeto, escopo.
Pedidos como "vídeo de demonstração", "demo do app", "walkthrough", ou simplesmente dar um link/localhost acionam a skill.
Conhecer os gatilhos garante que a skill certa entre em ação (e não a explicativo).
Frases-gatilho, dar o link, walkthrough.