DoubleWhopperS/video-craft-playbook

Video Craft Playbook

Este é um manual de ofícios de vídeo para agentes codificadores, ajudando você a enxergar antes de agir: ao fazer um vídeo de alta qualidade, quais capacidades visuais estão disponíveis; onde cada capacidade funciona bem, onde falha e qual seu custo; como combinações de casos anteriores foram feitas e quais pitfalls foram encontrados.

Este manual não determina qual ferramenta usar. Nenhuma ferramenta é padrão, nem há receita fixa: para o mesmo estilo visual e mesmo tipo de vídeo, sob restrições diferentes (orçamento, material, duração, necessidade de física real, necessidade de pessoas reais, número de revisões), a combinação adequada pode ser completamente diferente. A escolha é sua, baseada em um planejamento proposital para a tarefa atual; o manual fornece apenas fundamentos para julgamento.

Como usar

1. Antes de começar: verifique pendências de retorno

python3 ~/.agents/skills/video-craft-playbook/scripts/playbook.py status

status lista cartões de caso ainda não destilados (cases/inbox/), cartões de capacidade cujo prazo de revisão expirou e a contagem de itens na camada de espera (references/lessons-backlog.md); quando atingir o limite de indução, sugere executar consolidate. Na inbox só há cartões que na última vez foram julgados como merecedores de registro, mas não foram destilados. Havendo pendências, gaste alguns minutos destilando-as no manual (veja passo 4) antes de iniciar um novo vídeo; quando o tempo for curto, pelo menos informe ao usuário quantas pendências de retorno existem.

2. Planejamento: primeiro decompose requisitos expressivos, depois mapeie capacidades

Não comece por "qual ferramenta usar", mas por "como cada elemento deste vídeo se sustenta":

1. Decomponha o vídeo final em elementos: sujeito, ambiente, movimento, câmera, texto e gráficos, textura, som, ritmo.
2. Para cada elemento, responda às perguntas em references/task-lenses.md: de onde vem seu "realismo", precisa de precisão quadro a quadro, quantas revisões passará, pode pagar, qual o prazo.
3. Em references/capability-atlas.md, encontre pelo menos duas capacidades viáveis para cada elemento: primeiro varra a tabela de resumo no topo para candidatos, depois leia os cartões correspondentes; compare e selecione, anotando a razão da escolha e as alternativas descartadas. Entre os candidatos, inclua sempre "material real encontrável" (atlas grupo H: índice de material local, busca em acervos abertos); não compare apenas geração e código. A escada "texto → descrição de cena → busca → verificação de licença → composição" está na pergunta 11 de task-lenses e em craft-lessons L60.
4. Ao combinar várias capacidades, defina primeiro as interfaces: autoridade temporal, taxa de quadros, coordenadas e câmera, alpha, cor, barramento de áudio (seção 3 de task-lenses).
5. Antes de começar a execução, escreva uma "tabela de divisão de trabalho" (modelo na seção 4 de task-lenses), mostre-a ao usuário na primeira resposta e então execute, sem precisar aguardar confirmação.

Tarefas de edição (material já fornecido, principalmente corte e pós-produção) veja também a seção 6 de task-lenses: a decomposição das técnicas em componentes genéricos e regras "sinal → técnica" está em references/editing-grammar.md; os sinais e campos que a camada de entendimento deve produzir estão em references/edit-signals.md. Ambos são atualmente inferências; use como ponto de partida, e ao final julgue se podem ser promovidos.

A gramática de movimento ao nível de cena (abertura, transição, cartão de texto, entrada de interface, encerramento) pode ser consultada, após selecionar Remotion, no índice do repositório externo de receitas references/shot-vocabulary.md: procure por encaixe funcional e energia, depois vá ao repositório ler o cartão completo e o código demo; vem do contexto de vídeos promocionais, não verificado localmente.

references/composition-patterns.md registra como casos anteriores realmente combinaram capacidades, podendo inspirar e ajudar a estimar custos. São soluções para aquelas tarefas, não templates: antes de copiar, verifique se suas restrições são as mesmas.

3. Execução: ofícios e pitfalls

• Práticas que funcionam entre ferramentas (validação primeiro, tempo como única autoridade, quadro como função pura de t, camadas de revisão, pacote de pagamento, normas de áudio etc.) estão em references/craft-lessons.md.
• Pitfalls conhecidos agrupados por ferramenta estão em references/pitfalls.md. Antes de usar uma ferramenta, dê uma olhada em seu grupo.
• A forma de invocar cada ferramenta específica segue o Skill correspondente (cada cartão do atlas tem a entrada); este manual não repete detalhes de comandos.

4. Finalização: primeiro julgue se vale registrar, depois decida o retorno

O manual cresce com os casos, mas nem todo caso merece ser registrado: apenas repetir entradas existentes, ou detalhes que só valem para aquele vídeo, só diluiriam o manual. Ao entregar o vídeo (ou abortar a tarefa), siga a seção 1 de references/writeback.md para listar candidatos, passar pelos três portões (reuso, não dedutível, custo), e só conte o que passar com evidência; se puder ser fundido em entrada existente, não crie nova.

• Se houver um ou mais que contam: siga a seção 2 de writeback: new-case cria cartão de caso → destile nos arquivos correspondentes (quando a camada permanente estiver cheia, escreva em references/lessons-backlog.md) → check → close. Se não houver tempo para destilar, deixe o cartão na inbox; na próxima vez, status lembrará.
• Se nenhum contar: pule o retorno, não crie cartão de caso nem registre no diário. Se o usuário disser para não retornar, também pule.

Na nota final de entrega, inclua uma linha Retorno do Playbook com a conclusão: quais arquivos foram alterados, ou cartão de caso pendente de destilação, ou "Pulado: ".

Princípio da neutralidade (vale tanto para escrever quanto para usar o manual)

• Cartões de capacidade registram apenas fatos: no que é bom, no que não é bom, custo, determinismo, fonte de validação. Não escreva palavras de ordenação como "padrão", "preferido", "recomendado", "prioritário"; playbook.py check bloqueará essas palavras.
• A ordem dos cartões segue o tipo de mídia, não representa ranking.
• Se uma ferramenta funcionou bem em um caso, registre como "sob tais restrições, funcionou porque...", não generalize para "use esta ferramenta para este tipo de vídeo".
• Capacidades não validadas em casos locais também devem ser incluídas, marcadas como "instalado não validado" ou "inferido"; não omita por não ter usado, nem exagere por ter usado.
• Extensão também é tendenciosidade: campos de cartão têm tamanho fixo; listas de funcionalidades e detalhes de implementação não entram no cartão; ferramentas mais usadas não ganham mais espaço por isso.
• Se descobrir que algum registro carrega tendência (por exemplo, uma nota de workspace diz "por padrão escolha X"), ao retornar, reescreva como condicional: sob quais restrições é adequado.