Vídeo de lançamento para um produto de software
Produza um vídeo de 30 a 60 segundos que faça alguém entender e desejar o produto.
A decisão que molda tudo: reconstruir, não gravar
Gravações de tela lutam contra você. A latência real é ar morto. As regravações são caras. Você não consegue segurar um quadro, não consegue desacelerar uma batida e acelerar outra, e não consegue cortar com precisão sem atingir a compressão.
Portanto, reconstrua a interface como React orientado a frames dentro do Remotion. Cada visual é uma função pura de useCurrentFrame(). A digitação pousa em uma curva exata, um estado de carregamento se resolve na batida, e uma regravação custa um número.
Isso só é razoável porque você pode ler o código real do produto (se local) ou DOM+CSS (se hospedado) e reproduzi-lo fielmente. Faça isso — pegue os nomes de classe reais, as cores reais, o texto real. A reconstrução deve ser indistinguível de uma gravação, e depois melhor.
Quando gravar em vez disso: 3D pesado, conteúdo de vídeo dentro do produto, uma superfície Canvas/WebGL ou um aplicativo desktop nativo. Se uma superfície específica não puder ser reconstruída, grave apenas essa superfície e componha com <OffthreadVideo>.
Fase 1 — Entender o produto
Leia references/discovery.md antes de iniciar esta fase. Ela cobre o procedimento de navegação e triagem, a conversa sobre credenciais e como extrair um sistema de design de um site ativo.
Versão resumida:
- Dada uma URL: navegue por ela. Primeiro a página de destino (ela mostra como eles se posicionam), depois o aplicativo em si. Descubra qual problema o produto resolve e para quem.
- Dado um repositório local/servidor de desenvolvimento: leia o código. Muito mais rico — você obtém os componentes reais, os tokens de tema reais, os dados de seed reais.
- Faça a triagem das páginas. A maioria dos produtos tem 20 telas e 3 que importam. Autenticação, configurações, pagamento, privacidade, conta, integração — estes quase nunca são a história. Encontre a tela onde o produto faz aquilo que só ele pode fazer.
- Se o conteúdo relevante estiver atrás de um login, pergunte primeiro — credenciais de teste ou uma conta semeada no ambiente de desenvolvimento local. Se nenhum estiver disponível, não desista e não finja uma sessão que você nunca viu: mude para o formato de capítulos e construa a partir dos cards de funcionalidades, texto e componentes da própria página de destino.
discovery.mdtem o procedimento de coleta e as regras de honestidade.
Em seguida, confirme sua compreensão com o usuário antes de construir — uma leitura errada do produto custa uma construção inteira. Mostre a ele: o que você acha que o produto faz, as 2 a 4 telas que você planeja apresentar, o cenário principal, a lista de planos e a questão da música (veja a Fase 4). Um checkpoint, depois execute.
Fase 2 — Escolher o formato
Leia references/structure.md. Dois formatos funcionam; escolher errado custa a construção.
Formato A — a narrativa única. O padrão. Um usuário fazendo um trabalho e obtendo um artefato. Não é um tour de funcionalidades.
| batida | trabalho |
|---|---|
| Gancho (0–5s) | Enunciar o problema nas próprias palavras do espectador. Ainda sem interface. |
| Pergunta (5–12s) | O usuário pede a coisa. Foco no campo de entrada. |
| Trabalho (12–25s) | O produto visivelmente faz algo difícil. Mostre as provas. |
| Artefato (25–35s) | A saída, por completo, em tamanho legível. |
| Controle (35–45s) | O usuário altera e permanece no comando. |
| Placa (45–50s) | Logotipo, uma linha, domínio. |
As batidas Trabalho e Controle são o que separam uma demonstração real de um mockup. "Ele me perguntou ao invés de adivinhar" e "Eu pude editar o que ele fez" são argumentos de confiança, e confiança é o que um vídeo de lançamento realmente vende.
Escolha o momento em que o produto faz algo que uma pessoa não poderia fazer facilmente sozinha, e torne a saída concreta e visível — um documento gerado, um gráfico construído, um bug corrigido, um site implantado. Artefatos concretos são o que as pessoas lembram.
Formato B — o filme com capítulos de funcionalidades. Três funcionalidades, cada uma introduzida por um cartão de etiqueta em linguagem simples, depois mostrada.
gancho → [01 etiqueta → funcionalidade] → [02 etiqueta → funcionalidade] → [03 etiqueta → funcionalidade] → placa
Use-o quando o produto é fechado e você está trabalhando a partir de sua página de destino, ou quando as funcionalidades genuinamente não compartilham uma jornada de usuário, ou quando você quer três clipes independentes de uma única construção. Três é o número — quatro significa que nenhum deles se fixa.
Não coloque capítulos em uma sequência. Se as capacidades acontecem uma após a outra em uma única sessão (pesquisa → rascunho → edição), isso é um fluxo de trabalho, e etiquetá-lo como três funcionalidades luta contra o material. Se alguém pedir capítulos em um produto sequencial, ofereça o caminho do meio: mantenha a narrativa única e coloque as etiquetas sobre a ação à medida que cada capacidade aparece. Mesma legibilidade, mesmos limites de clipes, sem custo de tempo de execução, história intacta.
structure.md cobre o design do cartão de capítulo, como escrever as etiquetas (nomeie o resultado, não o mecanismo; roube as próprias palavras do produto), transições e ordenação.
Fase 3 — Fundamentar tudo
Qualquer que seja o domínio do produto, não invente seu conteúdo. Se for um produto jurídico, o estatuto deve ser real. Se for análise, os números devem ser plausíveis e internamente consistentes. Se for uma ferramenta de código, o código deve compilar na cabeça do leitor.
Extraia a coisa real do repositório, da API, dos dados de seed ou da documentação. Especialistas de domínio assistem a esses vídeos e um único detalhe inventado custa todos eles. Nomes de partes, datas e valores monetários são bons para inventar — esses são específicos de um cliente, não afirmações sobre o mundo.
Mantenha uma nota de proveniência no arquivo de dados dizendo de onde veio cada fato. O você do futuro vai querer isso.
Fase 4 — Construir
Execute o scaffold, que fixa as versões que realmente funcionam juntas e escreve a configuração:
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 45
Ele cria um projeto Remotion independente (seu próprio repositório git — nunca adicione ferramentas de vídeo ao repositório do produto a menos que seja solicitado), copia useCamera.ts e deixa um módulo de linha do tempo para você preencher.
Em seguida, nesta ordem:
-
src/timeline.ts— matemática de frames e limites de planos. Escolha um BPM cuja batida seja um número inteiro de frames (a 60fps: 120 BPM = 30 quadros, 90 BPM = 40). Coloque cada limite de plano em uma batida. Mesmo sem música, isso dá ao corte um ritmo interno, e significa que uma música de fundo pode ser adicionada mais tarde sem reedição. -
src/data/script.<lang>.ts— todas as strings, todos os números, cada pedaço de conteúdo de documento, em um único arquivo com comentários de proveniência. Nada codificado em componentes. Remarcar o tempo e traduzir ambos se tornam triviais. -
Componentes — recrie a interface do produto. Copie nomes de classe reais. Se o produto usa Tailwind, forneça sua configuração e CSS do tema; se ele usa variáveis CSS para cor, você deve trazê-las ou tudo será renderizado sem cor.
-
src/scenes/ProductScene.tsx— um objetoBexportado contendo cada batida como um número de frame absoluto. Tudo lê a partir dele: o DOM, a câmera, o som. Remarcar o tempo significa editar aquele bloco e nada mais.
Leia references/camera.md para o sistema de planos, references/motion.md para durações e tipografia.
Fase 5 — Áudio
Duas faixas, dois arquivos, duas tags <Audio>: efeitos e música. Mantenha-os separados para que qualquer um possa ser substituído sem regenerar o outro.
Efeitos — references/sound.md. A contenção é toda a disciplina: um vídeo de 45 segundos geralmente precisa de três a cinco eventos no total. Um 'pop' significa que uma coisa apareceu, um 'swish' significa que um elemento se moveu dentro do plano, um 'whoosh' significa que o plano se moveu.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Música — references/music.md. Pergunte antes de construir uma. A maioria das pessoas tem uma opinião e muitas já têm uma faixa; perguntar custa uma frase e pode salvar todo o esforço:
Você quer uma música de fundo? Se você tiver uma faixa, envie-a e eu cortarei para ela. Se não, posso sintetizar uma — energética, calma, cinematográfica, minimalista, acolhedora ou tensa?
Se eles tiverem uma faixa, corte para ela: encontre seu BPM, defina a linha do tempo para corresponder, mova os limites dos planos para suas barras. Caso contrário, sintetize uma faixa cuja mudança de arranjo aterrisse nos seus cortes para o quadro:
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Coloque uma entrada sections em cada limite de plano real, uma entrada hits no seu maior corte, e uma entrada ducks sob qualquer linha sustentada que você queira lida em vez de sentida. Música no pico ~0.30, efeitos em ~0.62. Escolha o clima baseado no que o produto é — assunto sério pede uma base mais calma, e um corte ocupado precisa de uma mais esparsa.
Fase 6 — Verificar com stills, antes de renderizar
Este é o loop apertado, e pular isso desperdiça horas.
npx remotion still <CompositionId> out/f0700.png --frame=700
Em seguida, olhe realmente para o PNG. Renderize um still por plano, mais um em cada transição. Verifique: o assunto está no quadro, algo está cortado no meio de uma palavra, há espaço morto, o texto se encaixa.
Adicione uma composição silenciosa (defaultProps: { withAudio: false }) para que os stills não precisem do arquivo de áudio para existir.
Ajuste numericamente sempre que possível. Curvas de easing, distâncias de rolagem, conteúdo espectral — tudo isso é computável. Escreva um script Python descartável que amostre a curva e imprima o que você de outra forma estaria adivinhando. É mais rápido que uma renderização e está correto.
Renderize o vídeo completo apenas quando os stills estiverem corretos.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Limite a concorrência a 4 em uma máquina de 16GB — o Remotion cria uma aba do Chrome por slot e o padrão (contagem de núcleos) vai gerar swap.
Fase 7 — Entregar honestamente
Envie o arquivo. Em seguida, diga claramente:
- O que você não pôde verificar. Você pode ler stills; não pode julgar como oito segundos parecem, e não pode ouvir o áudio. Diga isso.
- Qualquer tela que você reconstruiu em vez de observou — especialmente em um produto fechado. Liste-as e ofereça-se para refazer essas batidas se eles compartilharem acesso.
- Onde você fez uma escolha de julgamento com a qual eles possam discordar.
- Como trocar a música: coloque qualquer WAV ou MP3 em
public/music.wave renderize novamente. - Qualquer coisa que você encontrou no produto deles enquanto construía — um bug de renderização, um rótulo errado, um estado ausente. Você acabou de ler a interface deles com mais cuidado do que a maioria das pessoas jamais fará. Essa observação muitas vezes vale mais do que o vídeo.
Arquivos de referência
Leia estes quando chegar à fase relevante — eles são detalhados e não há valor em carregá-los todos de uma vez.
| arquivo | quando |
|---|---|
references/discovery.md | Fase 1 — navegação, triagem de páginas, credenciais, sistemas de design, e construção a partir da página de destino de um produto fechado |
references/structure.md | Fase 2 — narrativa única vs capítulos, design de cartão de capítulo, escrever rótulos de funcionalidades, transições, ordenação |
references/camera.md | Construindo planos — espaço de layout, câmera de ponto focal, corte vs push vs morph, isolando componentes |
references/motion.md | Durações de animação, tipografia, padrões de gancho, o carretel de perguntas |
references/sound.md | Design de som — o vocabulário pop/swish/whoosh, contenção, sintetizando teclado e cliques |
references/music.md | Obter vs sintetizar uma base, escolher um clima, alinhar seções aos cortes, mixar sob os efeitos |
references/pitfalls.md | Leia antes de sua primeira renderização. Bugs que custam horas reais, cada um com a correção. |
Scripts empacotados
<skill-dir> abaixo é o próprio diretório desta skill — o caminho fornecido a você quando a skill foi carregada. Não presuma uma localização de instalação fixa; a skill pode ser instalada pessoalmente, como um plugin, ou baixada em um projeto.
| script | o que faz |
|---|---|
scripts/scaffold_video.py | Cria o projeto Remotion com fixação de versões funcionais e configuração |
scripts/make_sfx.py | Sintetiza uma faixa de efeitos sonoros a partir de uma lista de eventos JSON. Sem samples, sem dependências além do numpy. |
scripts/make_music.py | Sintetiza uma música de fundo em um de seis climas, com seu arranjo alinhado ao seu corte. Mesmas dependências. |
assets/useCamera.ts | O hook de câmera de ponto focal — copie para src/hooks/ |
assets/ChapterCard.tsx | Cartão de capítulo para o formato de capítulos — copie para src/components/ |
A versão resumida
Reconstrua em vez de gravar. Uma história, um artefato — a menos que o produto seja fechado ou suas funcionalidades sejam genuinamente separadas, então três capítulos com rótulos simples. Fundamente cada fato de domínio. Quadros são a unidade de tudo. Isole um componente em vez de cortar a página. Movimento de interface é 150–300ms, movimentos de câmera são ~1s. Quatro sons é suficiente. Pergunte antes de fazer música. Olhe para os stills antes de renderizar. Diga o que você não pôde verificar e o que inferiu.