Projeto-para-Vídeo

O que Projeto-para-Vídeo faz?

Transforme qualquer projeto em um vídeo de marketing premium. O skill é executado dentro do repositório do projeto (ou contra uma URL), analisa o que o produto realmente é e produz um vídeo Remotion fundamentado em funcionalidades reais e UI real.

Regra de ouro: o pipeline é ANALISAR → STORYBOARD → APROVAR → CONSTRUIR → RENDERIZAR. Nunca escreva código Remotion antes do storyboard ser aprovado pelo usuário.

MODO AUTOMÁTICO: Se a solicitação do usuário contiver "completo automático", "sem interrupções", "de uma vez", "piloto automático" ou de outra forma solicitar claramente uma execução ininterrupta de ponta a ponta, mude para o modo automático: pule a pausa de aprovação do storyboard (escreva video/storyboard.md, declare que está prosseguindo no modo automático e continue direto para a construção), decida automaticamente quaisquer perguntas em aberto usando padrões sensíveis (arquétipo de explicador, 1080×1920 @ 30fps, tokens de marca pela ordem de prioridade padrão) e pare apenas para bloqueios genuínos (site inacessível, erros de renderização que sobrevivam a 3 tentativas de correção). Iniciar um servidor de desenvolvimento local ainda requer autorização explícita do usuário — mas trate "completo automático" como essa autorização se o usuário forneceu o comando de execução ou o repositório tem um comando de desenvolvimento padrão inequívoco (npm run dev, docker compose up). No modo automático, ainda entregue o storyboard junto com o MP4 para que o usuário possa revisar posteriormente e solicitar alterações em nível de cena.

Fase 0 — Detectar entradas

Estabeleça o que você tem para trabalhar, em ordem de prioridade:

1. URL ativa (produção ou UAT/staging) — melhor fonte. Peça ao usuário, se não for fornecida.
2. Servidor de desenvolvimento local — se o repositório estiver presente, mas nada estiver em execução, ofereça-se para iniciá-lo. Leia package.json / docker-compose.yml / Makefile / README para encontrar o comando de desenvolvimento. Peça ao usuário para confirmar antes de iniciar qualquer coisa (variáveis de ambiente, portas e bancos de dados variam). Se não puder ser iniciado, volte para análise apenas de código.
3. Apenas código — analise o repositório estaticamente; os visuais serão recriações SVG puras.

Pergunte também (ou infira do contexto):

• Qual arquétipo? (explicador / demonstração / lançamento / teaser — veja references/video-archetypes.md)
• Quais proporções de aspecto? Padrão: 1080×1920 vertical, 30 fps. Ofereça 16:9 e 1:1 como renderizações extras.
• Algum token de marca? Verifique se há um JSON de token de design no repositório; caso contrário, extraia cores/fontes do site ativo; caso contrário, use os padrões de assets/brand-theme.json.

Fase 1 — Analisar o projeto

Objetivo: um arquivo video/project-brief.md onde cada afirmação posterior pode ser rastreada.

Análise estática — leia README, docs/, texto da página de destino no repositório, estrutura de rotas/páginas, módulos de funcionalidades, nome do produto e slogan.

Análise ativa (se uma URL existir) — execute scripts/capture-screens.mjs com Playwright para:

• Capturar screenshots das páginas principais (home/hero, dashboard, 3–5 telas de funcionalidades principais) na proporção de aspecto alvo e no tamanho desktop
• Gravar capturas de tela curtas (3–6s) de 1–2 fluxos principais se o arquétipo for demonstração ou lançamento
• Extrair as cores, fontes e textos de título reais do site

Escreva video/project-brief.md contendo: o que é o produto, público-alvo, 5–7 funcionalidades principais (cada uma com a fonte da evidência), identidade visual (cores/fontes/logo) e a lista de ativos capturados com caminhos de arquivo.

Regra: sem funcionalidades inventadas, sem alegações exageradas. Se não estiver no repositório, docs ou site ativo, não vai para o vídeo.

Fase 2 — Storyboard (portão de aprovação obrigatório)

Leia references/video-archetypes.md para a estrutura de cenas e duração do arquétipo escolhido, depois preencha references/storyboard-template.md cena por cena usando SOMENTE material do brief do projeto.

• A narração é texto na tela, não narração em voz. Mantenha as linhas na tela curtas (máx. ~8 palavras por linha, máx. 2 linhas por vez) e coloque-as de modo que cada uma seja legível (~0,35s por palavra no mínimo na tela).
• Distribua o orçamento de quadros por cena antecipadamente para que o total corresponda exatamente à duração do arquétipo.
• Para cada cena, marque quais visuais são SVG e quais são capturas de UI reais em molduras de dispositivo (estilo híbrido — veja o documento de padrões).
• Inclua uma seção de sugestão de música e som no final (gênero, sensação de BPM, onde os acentos caem). Não obtenha nem incorpore arquivos de áudio.

Salve como video/storyboard.md, apresente ao usuário e PARE. Não prossiga até que o usuário aprove ou edite. (Exceção: no MODO AUTOMÁTICO, apresente o resumo do storyboard e continue imediatamente sem esperar.)

Fase 3 — Construir o projeto Remotion

Após a aprovação, leia references/remotion-standards.md na íntegra — ele contém os valores de animação necessários, regras de transição e os padrões híbridos de SVG + screenshot em moldura de dispositivo. Em seguida, crie a estrutura:

video/
├── remotion.config.ts
├── src/
│   ├── index.ts            # registerRoot
│   ├── Root.tsx            # <Composition> por proporção de aspecto
│   ├── config.ts           # fps, durações, orçamento de quadros por cena
│   ├── theme.ts            # TODAS cores/fontes/espaçamento — fonte única da verdade
│   ├── scenes/             # um arquivo por cena do storyboard
│   ├── components/         # DeviceFrame, CountUp, AnimatedChart, ConnectorLine, ParticleField, TextReveal…
│   └── assets/screens/     # Capturas da Fase 1 (importadas via staticFile)

Regras rígidas:

• Toda cor, fonte, raio e sombra vêm de theme.ts. Nenhum valor codificado nas cenas.
• As durações das cenas vêm de config.ts e devem somar o total do arquétipo.
• Todos os gráficos de diagrama/gráfico/ícone são SVG inline. A UI real do produto aparece apenas dentro dos componentes DeviceFrame usando as screenshots da Fase 1 — nunca finja uma screenshot de produto com SVG quando uma real existir.
• TypeScript em todo o projeto, Remotion 4.x, @remotion/transitions para mudanças de cena.

Fase 4 — Visualizar, renderizar, entregar

1. npx remotion studio — verifique cada animação, verifique a legibilidade do texto na velocidade de reprodução real, confirme o tempo.
2. Corrija problemas, depois npx remotion render <CompositionId> out/<arquétipo>-vertical.mp4.
3. Renderize proporções de aspecto adicionais, se solicitado.
4. Entregue: MP4(s), storyboard.md, project-brief.md e o projeto editável. Mencione que theme.ts e config.ts são os dois arquivos para ajustar para re-branding ou re-timing.

Arquivos de referência

• references/video-archetypes.md — estruturas de cena + durações para explicador (60s), demonstração (75–90s), lançamento de funcionalidade (30s), teaser (15s). Leia durante a Fase 0/2.
• references/storyboard-template.md — o formato de tabela por cena. Leia durante a Fase 2.
• references/remotion-standards.md — valores de animação, transições, padrões híbridos de moldura de dispositivo, regras SVG. Leia completamente antes da Fase 3.
• scripts/capture-screens.mjs — script de captura Playwright. Execute durante a Fase 1 (node scripts/capture-screens.mjs <url> <outDir>; requer npm i playwright + npx playwright install chromium).
• assets/brand-theme.json — tokens de marca substitutos; sobrescreva com valores extraídos do projeto sempre que possível.