SiuZheng/make-video

Fazer um vídeo

O usuário faz vídeos para o YouTube com você: explicações longas (16:9) e Shorts (9:16), animados em código com Remotion, narrados por uma voz do Gemini, geralmente com um sprite de personagem. Este skill é todo o processo. As ferramentas estão em <videokit>, a pasta videokit do repositório deste skill (leia references/toolkit.md antes de executar qualquer coisa). Se <videokit> não tiver sido substituído por um caminho real, pergunte ao usuário onde ele clonou o repositório (a pasta que contém vk.py) e use esse caminho.

O usuário se preocupa principalmente com três coisas, e é por isso que o processo é moldado assim:

1. Nada é construído antes que eles aprovem um rascunho. Eles querem ver a história e exatamente como cada cena vai parecer e soar – suas transições, animação, iluminação, efeitos sonoros e qualidade – primeiro. Mudar um plano custa minutos; mudar um render custa horas.
2. Tem que parecer profissional. Transições motivadas com desfoque de movimento, movimento suave, profundidade, iluminação real, um som para tudo que acontece, 1080p limpo. references/pro-look.md diz o que isso significa na prática e quais componentes realizam isso.
3. Eles querem o vídeo finalizado, não uma enxurrada de perguntas. Um agente revisor responde às perguntas ao longo do caminho e pontua o trabalho contra uma checklist fixa de 10 itens; o usuário recebe o vídeo assim que ele atingir 9/10. references/review.md é como: quem decide o quê, a checklist, os prompts e quando parar. As revisões vêm cedo (o rascunho, o animatic), quando as mudanças são baratas, não apenas no final.

As etapas

Cada ✋ é uma parada: aguarde a resposta antes de prosseguir. ✋ usuário: o usuário decide. ✋ revisor: o agente revisor decide (um agente para o vídeo inteiro, continuado com SendMessage – review.md).

0. O briefing ✋ usuário

Pergunte o que você não consegue deduzir da solicitação, com AskUserQuestion (até 4 perguntas por chamada; uma segunda chamada para o que restar). Não assuma nenhum destes, mesmo quando o tópico tornar um provável:

• Formato: vídeo longo (16:9, 1920×1080) · Short (9:16, 1080×1920, abaixo de 3 min) · ambos (um vídeo longo mais 3-5 Shorts cortados dele).
• Narração: voz de IA (Gemini TTS; você enviará amostras) · sem narração (música + palavras na tela) · a própria gravação do usuário.
• Estilo visual: ofereça 3-4 estilos concretos que combinem com o tópico (ex.: espaço cinematográfico desenhado em código com luz real; gráficos em movimento planos e limpos; rabisco à mão livre; recorte de papel de livro de histórias), cada um descrito em uma linha.
• Personagens: sprites de personagens existentes (em <videokit>/sprites; python vk.py characters lista eles) · novos personagens gerados com uma ferramenta de geração de imagem como Gemini (Nano Banana, custa dinheiro) · emoji · desenhados em código · nenhum.
• Todos os outros assets (adereços, objetos, ícones, fundos) – pergunte isso separadamente, sempre: desenhado em código (grátis; o visual da biblioteca de efeitos) · emoji (grátis; o componente Emoji, iluminado como todo o resto) · gerado com uma ferramenta de geração de imagem como Gemini (custa dinheiro) · uma mistura, decidido asset por asset no rascunho. Pergunte em todo vídeo. Imagens geradas só são feitas quando o usuário escolheu isso aqui.
• Música: uma trilha original (clima: maravilha/tensão/brincadeira/épico) · uma trilha composta nota a nota para este vídeo (um tema, acordes e acentos sincronizados com as cenas – toolkit.md "Uma trilha composta") · a própria música deles (eles enviam o áudio e a letra – nunca baixe) · nenhuma.

Também resolva o tópico, a duração e o idioma se não estiverem claros. Em seguida, crie o projeto: python -X utf8 vk.py new <pasta> --title "..." --format long|short|both (a partir da pasta videokit; o projeto é criado ao lado dela).

1. O rascunho ✋ revisor, depois ✋ usuário

Pesquise o tópico (verifique cada fato; anote qualquer coisa que dependa da data de hoje), escreva script.md (a narração, uma linha gravada por linha "> "), depois escreva plan.md a partir do modelo já no projeto. references/draft.md explica cada seção. O coração disso é a tabela cena por cena: para cada tomada, a narração, o que vemos (e o que o personagem faz nela), a câmera e a animação, a transição de entrada e saída, a iluminação e a cor, os efeitos sonoros e a música. Além disso, os planos de visual, movimento, iluminação, transição e som, as especificações de qualidade, os Shorts (se "ambos"), fatos com fontes e o custo. Escreva também 2-3 opções de gancho (cada uma uma primeira linha e um primeiro quadro). Para um Short, siga as regras de draft.md "Os primeiros 3 segundos": a surpresa em 1 s, uma ação com um som no quadro 0, um primeiro quadro brilhante. Números reais de Shorts mostram que as visualizações são ganhas ou perdidas ali; os do próprio usuário vão em references/channel-numbers.md.

A revisão do rascunho: convide o revisor com plan.md e script.md (review.md, "Invocando"). Corrija cada defeito que ele encontrar e tudo que o rascunho puder corrigir para os itens que pontuou abaixo de 2; incorpore a escolha de gancho dele no rascunho; registre o que você aceitou e o que não aceitou em out/review/decisions.md.

Depois mostre ao usuário: um breve resumo no chat (a história em algumas linhas, as cenas como uma lista compacta, qualquer coisa que você precise que eles decidam, e a pontuação projetada do revisor em uma linha) com um link para plan.md. Peça aprovação ou mudanças, revise e repita até que eles digam para prosseguir. Não grave, gere ou anime nada antes disso – esta é a regra do usuário.

2. Voz (se narrado)

• A voz padrão (video.json: Gemini "Kore" em speed 1.2) não precisa de pergunta. Uma nova voz ou estilo: vk.py voice samples → envie as amostras (SendUserFile) → ✋ usuário: eles escolhem pelo ouvido (agentes não podem ouvir, então esta nunca vai para o revisor). Defina em video.json, com speed.
• vk.py voice record (em cache; linhas idênticas são reutilizadas de outros projetos de graça), depois vk.py words (temporizações das palavras + uma verificação de que cada linha diz o que o script diz; ouça qualquer uma que ele sinalizar).
• Gemini 402 = os créditos pré-pagos acabaram: pare e avise o usuário.

3. Visual ✋ revisor

• Faça cada asset da maneira que a lista de assets do rascunho aprovado determinar (código, emoji, Gemini ou existente):
  • sprites existentes vão em CHARACTERS / PROP_DIRS em scripts/build.py;
  • gerados (apenas se aprovado): uma ferramenta de geração de imagem como Gemini (Nano Banana), recortada em PNGs transparentes e trazida da mesma forma (toolkit.md, "Imagens Gemini");
  • emoji: <Emoji char="🚀" .../> (fx/emoji.tsx) com a luz de borda da cena e uma sombra de contato;
  • código: desenhado na cena com a biblioteca fx (LitSphere, Sun, shapes, DrawPath...).
• Construa 3-4 quadros de estilo – os momentos-chave do rascunho, totalmente iluminados – como uma folha de contato (vk.py stills ...) e envie para o revisor ("Uma escolha ao longo do caminho"): aprovar o visual ou dizer o que mudar. Registre a resposta.

4. Construção

1. scripts/build.py: preencha a partir do rascunho – pausas, cues (c.at(line, 'phrase')), MOVES (como cada seção chega), effects() (um som para cada evento), music() (clima, arco de intensidade, acentos – ou a trilha composta), ambience(), o texto do YouTube. Execute vk.py build.

2. Cenas: um arquivo por cena em src/scenes/, escritas em segundos de história contra as cues, usando src/fx (câmera, camadas de profundidade, iluminação, partículas, texto cinético, a trilha do personagem). Liste-as em src/Video.tsx com suas transições. Mantenha o personagem dentro da ação (em cima de, montando, apontando para, reagindo ao que está na tela) – um personagem apenas flutuando parece preenchimento. Bloqueie cada tomada primeiro – posicionada, temporizada com suas cues e se movendo – antes da iluminação e da passada de riqueza. Movimento significa mais que o personagem: a partir do bloqueio, cada tomada tem uma câmera que deriva ou viaja, faixas de profundidade CamLayer e algo mais em movimento. Um Short que pontuou 20/20 com um mundo estático atrás do personagem ainda foi considerado muito simples depois que foi assistido em movimento.

3. O animatic ✋ revisor: vk.py animatic renderiza o vídeo inteiro na metade do tamanho com seu som real e sem desfoque de movimento (cerca de 1,5 min para um Short de 30 s) e executa as verificações de ritmo nele. Envie para o revisor (o prompt de animatic). Corrija o gancho, o tempo e a clareza agora, antes do polimento.

4. Shorts (se "ambos"): especificações em build.py via kit.shorts.build, uma cena por Short em src/shorts/.

5. Passada de riqueza: vá tomada por tomada contra "Tornar rico" em references/pro-look.md e adicione efeitos sempre que uma tomada estiver simples. Cada tomada precisa de:

   • um fundo com profundidade;
   • uma luz que você possa ver;
   • o sujeito inserido no mundo;
   • algo na frente;
   • uma câmera que nunca trava;
   • vida no fundo;
   • o acabamento;
   • o som.

   Todo vídeo deve parecer rico, então isso é parte do trabalho, não um extra. Mantenha as regras de contenção para que permaneça limpo e mantenha efeitos fora do texto.

5. Verificação (loop até ficar limpo)

vk.py qa renderiza cada cue e cada ponto médio de transição em folhas de contato (out/qa/) e então executa as verificações automáticas → out/qa/<comp>_checks.md: texto sob botões/títulos do YouTube/TikTok, menor que 44 px, sobreposto ou saindo do quadro (medido na própria página); e na renderização mais recente, estiramentos onde a imagem mal muda, tomadas onde o fundo fica parado (menos de 25% do quadro se movendo), lacunas na voz, faixas descobertas ao longo da borda do quadro, a costura do loop e o volume. Corrija todo problema que ele listar e dê uma olhada em cada "vale a pena olhar". Em seguida, percorra as folhas contra a checklist em references/pro-look.md – transições no meio, direção da iluminação, o personagem na cena, sem quadros simples (qualquer coisa que pareça plana ou vazia é enriquecida) – corrija e execute novamente (vk.py qa --auto executa apenas as verificações, cerca de um minuto). Faça um pequeno teste de render (vk.py render --frames 0-150) para ver o movimento real e a velocidade de render antes do render completo. Renders reutilizam cada bloco de 4 s cujos quadros não mudaram, então após uma correção basta executar o render novamente (--fresh apenas após alterar um desenho de canvas ou trocar um arquivo de vídeo).

6. Final ✋ revisor

• vk.py final (e vk.py final --comp Short-<id> para cada Short): 1080p H.264, com backup como v1/v2..., verificado quanto a tamanho, fps, codecs, -14 LUFS e pico verdadeiro. Sem cópias de pré-visualização para celular ou 720p – entregue apenas o arquivo 1080p. Em seguida, vk.py qa --auto nele.
• A revisão final (review.md, "Rodadas e quando parar"): o revisor pontua na checklist e escolhe o título. Corrija os defeitos e as correções mais bem classificadas, registre as decisões, renderize novamente e envie a nova versão com a anterior para comparação. Passa em 18/20 com nenhum item em 0 e nenhum defeito aberto; pare após 3 rodadas, ou antes quando uma rodada não encontrar nada novo e a pontuação se mantiver.
• TikTok (Shorts, quando o usuário os publica lá também): vk.py final --platform tiktok → "<Título> (TikTok).mp4": sem granulação, metade da poeira, uma taxa de bits mais alta e um leve sharpen, porque o TikTok reencoda cada upload com força.
• Miniatura (src/Thumbnail.tsx → 1280×720 jpg), captions.srt, youtube.md (título, descrição com capítulos, tags, a divulgação de voz de IA); shorts.md para Shorts.

7. Entrega

Envie o vídeo finalizado com SendUserFile quando estiver abaixo de ~30 MB (Shorts geralmente estão); caso contrário, forneça o caminho clicável (o corte do TikTok geralmente é maior: forneça o caminho dele). Resuma o que há nele cena por cena e como ele foi verificado: a pontuação final do revisor (e as rodadas anteriores), qualquer coisa ainda abaixo de 2, as anotações de canal do revisor (coisas sobre o canal como um todo – decisão deles) e que o revisor julgou o som apenas por medidores: a própria audição deles com som é a verificação final. Adicione as notas de upload. Em seguida, salve ou atualize uma nota de memória do projeto (o que foi feito, onde, decisões que o usuário tomou). Quando o usuário mais tarde perguntar como um Short publicado foi, adicione a linha dele em references/channel-numbers.md.

Regras que sempre se aplicam

references/house-rules.md contém as regras permanentes – leia uma vez por vídeo. A versão resumida: nunca imprima a chave da API; sem imagens Gemini sem um sim; nunca baixe músicas ou coloque letras de outros artistas na tela; perguntas "só perguntando" recebem respostas, não construções; rascunho antes de construir; apenas 1080p; o revisor responde às perguntas da etapa, enquanto o briefing, o rascunho, uma nova voz, dinheiro e qualquer coisa pública permanecem com o usuário.

Referências

• references/review.md – o agente revisor: quem decide o quê, a checklist de 10 itens, os prompts para cada etapa, o registro de decisões e quando parar.
• references/draft.md – como escrever o rascunho (plan.md) e apresentá-lo, incluindo as regras dos primeiros 3 segundos para Shorts.
• references/channel-numbers.md – um modelo para as próprias estatísticas do YouTube do usuário (taxa de retenção por Short, o que cada abertura fez) e como ler o Studio.
• references/pro-look.md – o padrão profissional: transições, animação, iluminação, partículas, tipo, som, verificações de qualidade, desempenho de render e os componentes para cada um.
• references/toolkit.md – comandos do videokit (as verificações automáticas, o animatic, o corte do TikTok), o layout do projeto, o relógio da história, hooks do build.py, Shorts, videoclipes, problemas do Windows.
• references/house-rules.md – as regras permanentes e por quê.