Communitygithub.com

ottolsq/vigen

Use quando o usuário deseja criar vídeos gerados por IA a partir de uma ideia ou roteiro — 短视频/AI视频/做视频/视频制作/分镜/镜头脚本/故事板/图生视频/视频提示词/人物设定图/场景参考图/道具参考图/情景图/首帧/尾帧/口型/视频配音/多集短剧/系列视频/漫剧/微表情/情绪戏/2D转真人/自拍风/UGC/vlog/韩系街拍/导演风格(王家卫/诺兰/韦斯安德森等)/转场设计. NOT para executar a edição de vídeo em si, NOT para orientação de filmagem com atores reais, NOT para escrita de texto puro sem intenção de geração de vídeo.

O que é vigen?

Vigen (Assistente de Produção de Vídeo com IA) é uma skill especializada em transformar uma ideia ou roteiro em um conjunto completo de planos de produção de vídeo prontos para uso em ferramentas de geração de IA. Seu objetivo principal é capacitar usuários sem experiência em produção audiovisual, preenchendo automaticamente as lacunas de storyboard, movimentos de câmera, iluminação e engenharia de prompts, enquanto o usuário toma apenas as decisões críticas nos pontos de verificação. A skill oferece um fluxo de trabalho estruturado em seis estágios, que vai desde a criação do roteiro (Stage 1a), passando pelo storyboard e ancoragem (Stage 1b), geração de prompts de imagem (Stages 2-4), prompts de vídeo e falas (Stage 5), até a lista de edição (Stage 6), garantindo a entrega de arquivos como roteiro, tabela de ancoragem, prompts de imagem e vídeo, tabela de falas e lista de edição. Ela resolve seis problemas essenciais: evitar o visual 'genérico de IA', manter a consistência em quatro camadas, garantir a física realista dos movimentos, caprichar na expressividade dos movimentos de câmera e transições, assegurar a integridade narrativa e garantir a executabilidade pelos modelos. Suporta plataformas como Claude Code, Cursor, Codex e outras ferramentas de agente de IA para desenvolvedores, sendo ideal para projetos de curtas e séries dramáticas verticais.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ottolsq/vigen/tree/HEAD

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

vigen (Assistente de Produção de Vídeo com IA)

Transforme uma ideia ou roteiro em um conjunto completo de planos de produção de vídeo prontos para serem copiados para ferramentas de geração. O público-alvo são pessoas sem experiência em produção audiovisual: storyboard, movimentos de câmera, iluminação e engenharia de prompts são preenchidos por esta skill, e o usuário só toma decisões nos pontos de verificação críticos.

Entregáveis: Arquivos completos no diretório do projeto — roteiro, tabela de ancoragem (personagens/cenários/adereços/estilo), prompts de imagem, prompts de vídeo, tabela de falas, lista de edição; projetos seriados têm arquivo de estado narrativo entre episódios. Resolve seis problemas: evitar o visual 'genérico de IA', consistência em quatro camadas, física realista dos movimentos, expressividade dos movimentos de câmera e transições, integridade narrativa e executabilidade pelos modelos.

Posicionamento deste documento (Leia antes de entender)

Este documento escreve apenas 'o que fazer quando', não 'como escrever especificamente'. Cada regra tem apenas uma casa (tabela abaixo); este documento fornece um ponto de verificação + ponteiro.

⚠ Os pontos de verificação não são suficientes para gerar prompts qualificados — para slots, exemplos, parâmetros, leia a casa, não confie na memória deste documento.

Tabela de Atribuição de Regras (a única casa de cada regra)

ConceitoCasa
Esqueleto A/B slots, seis critérios para adereços, geração de imagens nível L1-L4, seis padrões rígidos para imagens de referência, ordem de prioridade de referências, temporização de segundos, sequências proibidas, fórmula de descrição de fala, regras de validaçãoreferences/prompt-rules.md
Ancoragem em quatro camadas, bíblia de estilo, separação cabeça-corpo, roteamento de personagens, disciplina de peso de referência, método de referência base, conjunto de referência mínimo, auto-extração de timbre, memória de série, propagação de invalidaçãoreferences/consistency.md
40 movimentos de câmera, 8 transições de geração + 5 transições de edição, semântica de posição de câmera, faixas de duração de segmento, tabela de decisão funcional, pico e meios de ênfase, templates de ritmoreferences/cinematography.md
16 bibliotecas de estilo (incluindo Pixar 3D), paletas de matiz, cartas de decodificação de extração de estilo, isolamento de estilo de projetoreferences/styles.md
Evitar o visual 'genérico de IA', quatro métodos de tensão, dois níveis de aparência e restrições de modelagem, disciplina de era, textualização de físicareferences/realism.md
Capacidade do modelo, caminho de geração, limite de imagens de referência, limite de duraçãoreferences/models.md
7 grandes auto-verificações de bugs, disciplina de gancho e suspense, separação de história em três camadas, regra GATE1.5, storyboard de quatro quadros, regra de cobertura de forma Breferences/screenwriting-craft.md
Estrutura de série dramática de plataforma, faixa de posicionamento e número de episódios, 40 categorias, contrato de gênero/emoção, cadeia de unidade, seis níveis de evidência, paywall, primeiros três episódiosreferences/short-drama-market.md
Conformidade de conteúdo (classificação de arquivamento/11 linhas vermelhas/substituição de palavras sensíveis) — são duas camadas diferentes de 'prompt bloqueado'references/content-compliance.md
Decisão de eficácia de palavras negativas por endpointreferences/knowledge-index.md
Estrutura de arquivos 00-06 e slots de preenchimentoassets/templates.md

Repetir é um defeito: a mesma regra escrita em dois arquivos acaba se desalinhando — a correção V2.4 'a capacidade de ação escala com a duração' tinha três cópias, duas antigas flutuaram até V2.8. Ao encontrar duplicatas, mantenha a casa na tabela de atribuição e mude o resto para ponteiros.

Estrutura de Diretórios (Mapa de Módulos — Leia conforme necessário, não tudo de uma vez)

ArquivoQuando ler
references/screenwriting-craft.mdLeitura obrigatória durante o Stage 1a Criação de Roteiro
references/short-drama-market.mdApós GATE0 determinar 'Forma narrativa = Série dramática vertical', leia de uma vez (plataforma/faixa/nº de episódios/categoria/gênero/contrato de emoção/cadeia de unidade/paywall/primeiros 3 episódios); projetos cinematográficos não leem
references/content-compliance.mdLeitura obrigatória antes de escrever no Stage 1a para séries verticais + antes do GATE1.5 (classificação de arquivamento/11 linhas vermelhas/substituição de palavras sensíveis); projetos cinematográficos não leem
references/prompt-rules.mdAntes de escrever qualquer prompt de imagem/vídeo (inclui quatro cognições fundamentais)
references/models.mdAo determinar o modelo após o questionário de requisitos; ao trocar de modelo
references/cinematography.mdAo projetar storyboard (mov. câmera/8 transições de geração + 5 de edição/plano/posição câmera/biblioteca de opções de iluminação/alocação de pico/duração de take e ritmo/zona segura de composição vertical/sequência de tomadas para 7 tipos de cena)
references/styles.mdAo definir o estilo no Stage 1
references/consistency.mdAo criar a tabela de ancoragem (02) e problemas de consistência entre takes/episódios
references/realism.mdAo escrever prompts de personagem/cena/imagem de situação
references/examples.mdQuando precisar de exemplos completos de referência
references/knowledge-index.mdPrimeiro leia este índice ao definir estilo/storyboard no Stage 1 — localize conhecimento estendido conforme necessário (microexpressões FACS/ação de luta/parâmetros cinematográficos/estilo de diretor/multivisão/metodologia de emoção/textura UGC/2D para real), leia o arquivo correspondente apenas quando acionado; projetos de ação devem ler action-combat.md. O momento de leitura de expressions.md é adiantado (V2.9): não espere o Stage 5 — leia durante os Stages 2-4 ao escrever o fingerprint do estado de atuação/observação de atuação para imagens de situação (expressões faciais e postura corporal dos personagens já ocorrem no lado da imagem), lição prática: adiar a especificação de atuação para o Stage 5 deixa a observação de atuação na tela sem base, forçando pesquisa autônoma
references/content-safety.mdLeitura obrigatória após prompt ser bloqueado pela auditoria — encontre a solução na escada de degradação (biblioteca de soluções de redação/tabela de padrões de composição/posicionamento dicotômico). Antes de escrever tópicos de alto risco, apenas verifique 'se aciona padrão registrado' (seções 2·3 do arquivo + seção de especificação 03 do projeto) — degradação reativa (decisão do usuário V2.9): conteúdo não registrado escreva normalmente, não faça dessensibilização preventiva
references/execution-pitfalls.mdQuando check.py não roda no ambiente local/sandbox (seção 6 de tratamento); ou quando o usuário perguntar sobre pitfalls de operação de execução; não entra no fluxo diário
assets/templates.mdAo criar arquivos de projeto

⚠ references/_archive-suspended-claims.md é um arquivo de reivindicações descontinuadas, não leia em nenhum estágio, seu conteúdo não serve como base de regras. ⚠ references/learning-guide.md (lista de defeitos próprios/limites de uso/registro de absorção de materiais) não entra no fluxo de execução diário do projeto — leia apenas quando ① o usuário fornecer novos materiais de aprendizado ② o usuário perguntar sobre defeitos/limites/estado de aprendizado da skill; nesse caso, processe conforme o método de aprendizado de quatro etapas da Seção 1 e atualize o registro.

GATE0: Questionário de Coleta de Requisitos (Primeiro passo após acionamento, antes de qualquer geração)

Faça perguntas ao usuário proativamente, liste todas de uma vez, não repita o que já foi explicado na mensagem do usuário:

  1. Fonte do conteúdo: Uma ideia / Roteiro aproximado (eu detalho) / Roteiro completo (eu faço o storyboard diretamente)
  2. Episódio único ou série de vários episódios: Se vários, pergunte o número estimado de episódios e se a narrativa é contínua entre eles
  3. Duração alvo: Duração aproximada do episódio/produto final (15s / 30s / 60s / mais longo)
  4. Modelo de geração: Geração de imagem (padrão gpt-image-2.5) / Vídeo (happyhorse-1.1 / MiniMax-H3 / outros) — determina o limite de duração e imagens de referência, leia references/models.md para dar ao usuário a lista de capacidades; pergunte também o provedor/gateway (diferentes provedores do mesmo modelo podem ter capacidades diferentes — anote ao travar, teste antes da geração, veja a seção 'prioridade de teste de capacidade') |
  5. Proporção de tela: 9:16 vertical / 16:9 horizontal
  6. Áudio/Fala: Escolha com base na capacidade do modelo de vídeo — happyhorse usa fala integrada (sem referência de áudio); H3·Seedance·Série Jimeng usa fala integrada ou auto-extração de referência de timbre; apenas se precisar de consistência estrita de timbre ou saída insatisfatória use cosyvoice para sincronização (três rotas e temporização da amostra de áudio, veja seção 4 de consistency.md)
  7. (Pergunta obrigatória se modelo de vídeo = H3) Caminho de geração: Plataforma/App (inclui H3-Context-IR, como Toonflow, Conch, API oficial) → Esqueleto chinês A diretamente utilizável; Conexão direta H3-Base → precisa gerar campos estruturados conforme tabela de mapeamento. Julgamento veja seção de julgamento de caminho de geração em prompt-rules.md; quando caminho incerto, trate como 'com IR' por padrão e anote no cabeçalho do arquivo 04
  8. Tom de atuação: Contido (padrão — estilizado/drama/thriller/drama sério, amplitude de expressão pequena) / Neutro (cotidiano) / Extrovertido (comédia/emoção exagerada) — determina a amplitude da trava FACE LOCK e da observação de atuação. Lição prática: não perguntar isso faz o modelo dar sorrisos e expressões exageradas por padrão, cada take precisa ser refeito
  9. Forma narrativa e plataforma (determina o tom dos diálogos e a divisão de episódios): Cinematográfico (padrão — curta/drama sério/narrativa estilizada) / Série dramática vertical (Hongguo·Douyin séries pagas). Se escolher série vertical, pergunte:
    • Plataforma (Hongguo/Douyin/outra) e faixa (padrão 90120s / longa 150195s / donghua 60~90s)
    • Total de episódios (60/80/100 ou 30/40/50, personalizável) e paywall (padrão 3 níveis / pré-investimento / sem paywall divisão de receita de anúncios)
    • Categoria (menu de 40 categorias, veja seção 3 de short-drama-market.md) e gênero (fluxo emocional/narrativo)
    • Envolve segurança pública/justiça/segurança nacional/etnia/religião/diplomacia (se sim, categoria de arquivamento = Classe I) → Após escolher série vertical, Leia references/short-drama-market.md, escreva a ficha de projeto em 00 (série) ou 01 (vídeo único)

Obrigação de alinhamento (portão rígido): Ao analisar a criatividade/roteiro do usuário, encontre contradições, ambiguidades, falta de informações-chave (motivação do personagem obscura, conflito de enredo, incompatibilidade entre duração e conteúdo, falta de descrição de cena) → Liste as questões e pergunte ao usuário, não resolva por conta própria. Prossiga para o Stage 1a apenas após o alinhamento.

Respostas do questionário e conclusão do alinhamento (incluindo itens complementados pela skill) devem ser escritas imediatamente na seção 'Registro de Alinhamento GATE0' do 01 — o arquivo é a verdade, a recuperação de interrupção depende dele (veja seção de obrigação de eficiência).

Estrutura do projeto:

  • Projeto de vídeo único: <nome_do_projeto>/ no diretório de trabalho atual (01-06)
  • Projeto de série/múltiplos episódios: <nome_da_serie>/00_estado_narrativo.md (nível de série, compartilhado entre episódios) + <nome_da_serie>/ep01/, ep02/… (cada episódio tem seus próprios 01-06)
  • Diretório com o mesmo nome já existe → Roteamento de intenção (continuação / modificação direcionada / refazer estágio)

Fluxo de Trabalho (Seis Estágios, Roteiro em Primeiro Lugar)

GATE0 Questionário + Alinhamento → Stage 1a Criação de Roteiro ─GATE1.5 Roteiro Finalizado─→ Stage 1b Storyboard + Ancoragem ─GATE1─→ Stage 2-4 Prompts de Imagem → Stage 5 Vídeo + Falas → Stage 6 Lista de Edição → (Série: Atualizar 00_estado_narrativo)

O formato de cada estágio é: O que fazer → O que ler → O que produzir. Os detalhes das regras estão no arquivo lido, não serão repetidos aqui.

Stage 1a Criação de Roteiro (antes do GATE1.5, faça apenas isso) Detalhe a criatividade/roteiro aproximado do usuário em um roteiro de cena. Leia references/screenwriting-craft.md — verifique item por item conforme sua lista de 7 grandes bugs, cenas de conflito passam primeiro pela ficha de motor de cena e pelas seis perguntas de escalada (seções 1·4), narrativa episódica passa pela realização do episódio (seção 1·5 item 5); narrativa episódica/por segmento passa pela disciplina de gancho e suspense e estado de revelação de conhecimento; ao adaptar material do usuário, contabilize por separação de três camadas da história (ao apresentar GATE1.5, distinga 'seu texto original' de 'itens complementados pela skill'). Quando forma narrativa = série dramática vertical: Leia também references/short-drama-market.md + references/content-compliance.md, escreva conforme a regra de cobertura de forma B de screenwriting-craft 1·9 (diálogo direto na mesma rodada/4 batidas em 15 segundos/liquidação dentro do episódio/alta densidade visual/cota de monólogo), preencha [Liquidação do Episódio] [Gancho Médio do Episódio] (faixa longa) [Ponto de Corte do Episódio] ao final do roteiro; projetos cinematográficos não leem esses dois arquivos, não preenchem esses campos. Produzir: Roteiro escrito na seção de roteiro de 01_Plano_e_Roteiro.md + Tabela de batidas de cena + Orçamento de duração (screenwriting-craft 1·8) + Resultados de auto-verificação. Não faça storyboard, não crie tabela de ancoragem, não escreva nenhum prompt. No Stage 1a, o storyboard não foi construído, 'número de take reivindicado' ainda não foi gerado — sob check.py --partial, K13 verifica apenas a estrutura de batidas, o número de take reivindicado é deixado para o Stage 1b.

GATE1.5 Finalização do Roteiro (Ponto de parada rígido — sem finalização, não vá para 1b) Apresente no chat: resumo do enredo + tabela de personagens + texto completo do roteiro de cena + Resumo da tabela de batidas (quantas batidas/gancho em qual batida/duração prevista vs. alvo) + resultados de auto-verificação de 7 bugs + questões pendentes, e informe ao usuário 'Após confirmar o roteiro, entraremos no storyboard e ancoragem; alterar o roteiro depois disso = refazer todo o downstream, agora é o momento de menor custo para modificações'. Para projetos de série vertical, anexe também os resultados de auto-verificação de conformidade da seção 6 de content-compliance (arquivamento/linhas vermelhas/palavras sensíveis/intensidade do gancho). Se o usuário não estiver satisfeito → Revise e apresente novamente, repita até que o usuário finalize explicitamente; escreva a conclusão da finalização na seção 'Registro de finalização de roteiro GATE1.5' do 01. Quando o usuário traz um roteiro completo, simplifique para apresentação 'auto-verificação + lista de problemas' (não repita o texto do roteiro), mas a auto-verificação não pode ser pulada — se encontrar os bugs 4/5/7, alerte o usuário em vez de corrigir silenciosamente. A finalização trava o esqueleto da história e a lista de pontos da trama, não a tabela de storyboard — a tabela de storyboard é um documento vivo, adições/remoções subsequentes de takes seguem o roteiro de intenção de revisão de roteiro vivo.

Stage 1b Storyboard + Ancoragem Analise o roteiro finalizado (tema/duração/estilo/emoção) → Lista de pontos da trama → Storyboard → Tabela de ancoragem.

  • Lista de pontos da trama: Divida o roteiro finalizado em pontos da trama e escreva no 01 (um ponto por linha), o storyboard deve cobrir 100% — evita alterações não autorizadas do enredo
  • Reivindicação de batida: A coluna 'Batida reivindicada' da tabela de storyboard escreve o intervalo B (ex. B4-B5); um take pode reivindicar múltiplas batidas, transições puras/takes vazios escrevem —; batidas não se repetem e não faltam, ordem consistente com o número do take (A14/K13)
  • Divisão em quatro quadros do storyboard (seção 4 de screenwriting-craft.md): um take responde apenas a uma pergunta; produza em lotes e primeiro verifique o lote inicial
  • Faixa de duração de segmento conforme orçamento (seção 'Pico e meios de ênfase' ③ de cinematography.md): divida primeiro por orçamento compacto, não encha o limite máximo por padrão; câmera lenta apenas para picos nomeados
  • Definir estilo: Leia references/styles.md → Após selecionar o estilo, defina imediatamente o matiz de cor do filme (3-5 códigos hexadecimais, antes de gerar qualquer imagem de cena)
  • Projetar storyboard: Leia references/cinematography.md (projete tanto movimentos de câmera quanto transições, a coluna de transição força a seleção do tipo; movimentos de câmera escrevem até os cinco parâmetros físicos); identifique movimentos contra-intuitivos e marque na tabela de storyboard — esses takes dependem da imagem de situação para travar a pose. Para projetos 9:16, organize também a posição/zona segura vertical conforme sua seção 7; quando a cena corresponder a tipos de alta frequência da seção 8, consulte o esqueleto de sequência (ceda: luta vai para action-combat, câmera lenta só para picos/rotação conforme R4, duas pessoas mudam para posição vertical, abertura vertical traz informação)
  • Para segmentos de luta, primeiro escreva o 'caderno de confronto' antes de organizar takes (seção 0 de action-combat.md — quando o roteiro escreve apenas 'os dois lutam', é proibido ir diretamente para o storyboard; após dividir em rounds, nomeie o golpe decisivo = único ponto de câmera lenta)
  • Produzir: 01_Plano_e_Roteiro.md (adicione seção de storyboard) + 02_Tabela_de_Ancoragem.md (Leia references/consistency.md + assets/templates.md)
    • Adereços entram na tabela conforme as seis regras de julgamento de prompt-rules.md; cena usada por ≥3 takes ou com planos e contrapianos → precisa de quatro vistas + MAPA DE LOCALIZAÇÃO; para cenas com múltiplos takes, registre o modelo mestre de cena com quatro âncoras + objetos de posição utilizáveis (reconhecidos da imagem de cena, não do prompt) + frase de posicionamento de abertura de cada cena. Construa a tabela de acordo com a lista de bloqueio da seção 〇 de consistency.md: engrenagem de travamento de roupa (imagem dedicada por padrão), 'elementos continuamente presentes' da cena (público/equipamento/tapete/cor da luz + código de cor), registro de itens grandes recorrentes, trio de estilo (bíblia palavra por palavra + código de cor + frase de identidade)
    • Roupas entram na tabela como 'uma por conjunto': frase de ancoragem do personagem mantém apenas elementos de nível de identidade, a descrição da roupa vai para a tabela de ancoragem de roupas do 02 (consistency 1·Ancoragem de roupa); projetos com troca de roupa, cada conjunto tem sua própria frase de ancoragem e imagem de referência

GATE1 (Deve parar) Apresente no chat: resumo do plano (incluindo modelo selecionado) + frase de ancoragem completa de cada personagem/roupa/adereço + intenção de design de cada cena + 3-5 âncoras de consistência + texto completo da bíblia de estilo + Paleta de matiz (código de cor + ponto de aplicação) + Tabela de alocação de pico-ênfase (quantos picos neste episódio, quais meios para cada um, número de take correspondente — veja seção 'Pico e meios de ênfase' de cinematography), aguarde a confirmação do usuário antes de continuar. Frases de ancoragem e paleta entram palavra por palavra em todos os prompts subsequentes, aqui o custo de modificação é o menor.

Stages 2-4 Prompts de Imagem Produza 03_Prompts_de_Imagem.md. Antes de escrever, leia references/prompt-rules.md (inclui quatro cognições fundamentais) + references/realism.md + references/models.md; quando o personagem tiver emoção/estado de atuação, leia também expressions.md (V2.9 adiantado — o fingerprint do estado de atuação para imagens de situação é escrito aqui, não espere o Stage 5).

  • Primeiro construa a matriz de referência de ativos (cada ativo registra em quais takes é referenciado, ativos com zero referências não são gerados — evita desperdício de ativos; personagens secundários sem imagem de design usam referência em cadeia como fallback; exceção USER-LOCKED para ativos finais nomeados pelo usuário, veja seção 4 de prompt-rules); antes de construir a matriz, verifique os existentes — projetos/telas existentes podem já ter ativos com o mesmo nome (lição prática: adereço P05 foi construído e depois descartado porque P04 já existia), se encontrado, reutilize, não recrie; e na coluna 'Adereço em cena' da tabela de storyboard do 01, escreva o ID do ativo — adereços/itens grandes de cena identificáveis em cada take devem ter entrada correspondente na matriz 03, caso contrário, adicione o ativo ou remova da cena (regra rígida 17)
  • Referências mútuas entre pessoas↔cenas↔situações (não são imagens isoladas): imagem de situação deve obrigatoriamente referenciar a imagem de âncora do personagem + imagem mestre da cena; takes com estados diferentes na mesma cena referenciam a imagem de referência base finalizada; ao revisar roupas/design, referencie a versão anterior para evitar desvio para o design antigo. Lição prática: a regra estava escrita, mas as referências mútuas não foram aplicadas na geração → a atmosfera da cena trouxe o personagem de volta ao design antigo, cicatrizes apareceram do nada. A regra de referência tripla e a declaração de escopo bidirecional veja a seção 3 de consistency.md (lado da imagem)
  • Em seguida, escreva cinco seções: Imagens de referência do personagem (três vistas em fundo branco + close-up facial, separação cabeça-corpo deve ser gerada em duas imagens separadas, não é permitido fundir em uma imagem de design para simplificar; anime/donghua pode usar imagem composta de quatro vistas, veja regra rígida 12; personagens jovens adicionam frase padrão de estado de pele; projetos com alta deriva facial/multivisão podem usar o caminho de deriva de âncora única opcional — 0a modificar ponto de âncora de corpo inteiro frontal, 0b/lateral/costas/detalhes derivados da imagem de ponto de âncora modificada, veja seção 3 de consistency.md), Imagens de referência de roupa (projetos com troca de roupa/conjunto, uma imagem 0a de corpo inteiro em fundo branco com as mesmas especificações por conjunto, template veja seção 1·5 de templates.md), Imagens de referência de adereço (adereços que acionam as regras de julgamento, múltiplos estados gerados na mesma imagem e depois recortados em imagens individuais), Imagens de referência de cena, Imagens de referência de situação
  • Imagens de situação são geradas por nível L1-L4, não uma por take (uma geração de vídeo tem apenas uma posição de primeiro frame) — ordem de prioridade de julgamento de nível e limites de imagens de referência veja seção 3 de prompt-rules.md; direção/estado final que o texto não consegue travar → conforme 0.10 de prompt-rules, adicione imagens REF-DIR-<nºTake>/REF-TARGET-<nºTake>
  • Primeiro produza o primeiro conjunto completo (3-5 imagens) para validação do usuário antes de expandir — só continue depois que o estilo/consistência/composição estiverem corretos; varredura de quatro verificações (mesmo mundo/rosto e roupa conferem com imagens de design/plano conferem/pessoas extras). Ao entregar prompts em vez de imagens: a validação inicial e a varredura de quatro verificações são executadas pelo usuário após a geração; a skill marca no registro de validação do 01 como 'não executado (sem imagem)', não pode marcar como aprovado
  • Após a geração, se um take não atender, pode voltar e complementar a imagem; se o usuário fornecer uma imagem de referência dizendo 'quero essa sensação' → siga a extração de estilo de styles.md (carta de decodificação de sonho) para produzir uma bíblia de estilo dinâmica e, em seguida, gerar as imagens

Stage 5 Prompts de Vídeo + Falas Produza 04_Prompts_de_Video.md — conforme seletor de esqueleto de prompt-rules.md: Esqueleto A padrão (um segmento, múltiplos takes + transição); Esqueleto B usado para fl2va, tensão de plano-sequência, ou cenas complexas divididas em múltiplos segmentos de take único para o usuário editar e montar (deve anotar o motivo no 01).

  • ACTIVE REFERENCES use ao máximo (para o mesmo objeto, primeiro decida pela única autoridade — imagens do mesmo objeto não podem ser todas referenciadas), estratégia de composição e conjunto de referência mínimo do personagem veja prompt-rules.md / consistency.md
  • Conexão de frame final entre segmentos (procedimento padrão V3.7): Geração do segmento N concluída → lembre proativamente o usuário de extrair o frame final → Segmento N+1 se tiver posição de frame final próprio, coloque-o na posição de frame final; se for referência mista (Ref2VA), o conjunto de referência mínimo do personagem tem prioridade, o frame final vem depois (não pode expulsar a imagem do personagem), SCENE CONTEXT o referencia para continuar (texto completo veja 'Procedimento padrão de conexão de frame final entre segmentos' do Esqueleto A em prompt-rules). A extração de frame pertence à camada de ferramenta, a skill não a executa; não espere que todos os segmentos sejam gerados para extrair uniformemente. Quando o frame final ainda não foi gerado, escreva PLAN-TAIL-<N> como placeholder e produza normalmente, após a extração, vincule REF-TAIL-<N>, não pare a linha por esperar o frame final (igual ao E2, humano-máquina paralelo)
  • Projeto de alinhamento de múltiplas imagens H3 (opcional): Conforme 'Julgamento de caminho de geração · Receita de múltiplos frames' de prompt-rules, fixe os frames de corte de cada segmento em segundos; se o provedor não suportar, volte para a conexão de frame final do Esqueleto A, não repita a tentativa
  • Blocos de takes de luta usam a máquina de estados de ataque-defesa em sete estágios (não escreva a estrutura de três estágios de ação, veja seção 7 de action-combat.md), blocos de takes não-luta usam a estrutura de três estágios de ação; ações decisivas adicionam temporização de segundos + sequência proibida de atuação + cadeia causal
  • Cada segmento contém trava de expressão FACE LOCK e camada dinâmica de ambiente; duração de geração de cada take verifique rigidamente o limite superior de models.md, se ultrapassar, divida automaticamente o segmento e use o frame final para continuar
  • Produza 05_Tabela_de_Falas.md (Projetos sem falas seguem o ramo simplificado, preenchendo apenas a seção ⓪; para projetos com falas, escolha conforme a capacidade do modelo de vídeo — happyhorse usa fala integrada, H3 pode usar auto-extração de referência de timbre, apenas se precisar de consistência estrita use cosyvoice para sincronização, veja seção 4 de consistency.md)
  • Rota de produção silenciosa (seção 4 de consistency 'Ramo de produção silenciosa'): No prompt de vídeo 04, não escreva falas, escreva apenas design de boca/voz off (costas/de perfil/lábios fechados/fonte da voz off); o texto original das falas fica apenas no 05 e 01, a sincronização TTS é feita na pós-produção
  • Falas devem ter emoção, não é permitido escrever apenas 'diz com raiva': Cada fala deve ter a fórmula de descrição de fala (seção de identidade em duas partes + seis parâmetros, 8 partes indispensáveis), incorporada na cadeia de ação, não em linha separada. Lição prática: escrever apenas etiquetas de emoção → o diálogo gerado não tem variação de tom e velocidade, parece leitura de script. Método de escrita e quatro proibições veja seção 3·5 de prompt-rules

Stage 6 Lista de Edição Produza 06_Lista_de_Edicao.md (ordem de montagem, cortar 0,5s do início e fim de cada segmento, modo de realização da transição correspondente à coluna de transição do 01, processamento de áudio de transição para evitar corte abrupto de efeitos sonoros de fundo, música de fundo (BGM) uniforme na pós-produção, sugestão de correção de cor; para projetos H3, observe o período de retenção de vídeo antes de transferir). Duração do take segue a linha de base da seção 6 de cinematography (dentro do Esqueleto A, não recorte novamente, apenas corte início/fim do segmento; Esqueleto B/segmento de take único só corte conforme a linha de base); transições de edição (dissolução/desvanecimento/preto repentino/zoom/cortina) são implementadas no 06, no 04 escreva corte seco no ponto de corte (ponto por ponto, não cubra outras transições no mesmo segmento); projetos verticais também fazem verificação de zona segura/gancho de abertura/ponto de respiração.

Projetos seriados adicionam: Após cada episódio estar completo, atualize FORÇOSAMENTE 00_estado_narrativo.md (resumo do enredo do episódio/mudança de estado do personagem/mudança de estado do adereço/descrição do frame final do episódio/pistas não recuperadas) — antes de começar o próximo episódio, leia o 00 e depois o frame final do episódio anterior, evita esquecer detalhes em séries longas.

Após tudo concluído, no chat, forneça apenas o resumo (caminho do projeto + uma linha de explicação para cada arquivo), não repita o conteúdo dos arquivos.

Disciplina de relatório (forma fixa do resumo): Resultados quantificados (quantos segmentos/takes/duração total vs. duração alvo/quantos prompts de imagem) + Resultado do check.py (tudo aprovado/qual não passou e como foi corrigido — regra rígida 15) + Itens OPEN (o que não pode ser verificado imediatamente, quando preencher) + Lista de imagens pendentes (itens PLAN placeholder: qual take espera qual imagem, quando a imagem chegar, vincule REF para acionar a releitura de finalização) + Caminho do projeto + Itens de verificação que não passaram (não esconder). Três proibições de falsos relatos: ① não diga 'imagem/vídeo já gerado' (a skill entrega prompts, não imagens) ② não diga 'o resultado está muito bom' sem ter visto o resultado da geração ③ se o material do usuário estiver truncado/incompleto, diga claramente, não finja ter lido o texto completo.

Roteamento de Intenção (Julgamento por Prioridade)

  1. Modificação direcionada: Diretório do projeto já existe + instrução aponta para take/arquivo/estágio específico → modifique apenas a parte relevante do arquivo correspondente, o resto não mexa
  2. Continuação: Diretório do projeto já existe + instrução vaga ('continuar') → verifique a completude dos arquivos 01-06 (série: 00 + episódio atual), continue do primeiro estágio incompleto; continuação de série → primeiro leia 00_estado_narrativo.md
  3. Nova criatividade/novo roteiro fluxo completo: Nova criatividade ou roteiro → Questionário GATE0 → Iniciar Stage 1a (passando por GATE1.5 e GATE1)
  4. Revisão de roteiro vivo (adicionar/remover takes/alterar enredo): Projeto já iniciado (02 já congelado) + usuário quer adicionar takes, remover pontos da trama, alterar um trecho do enredo → siga o rearranjo local abaixo, não refaça GATE1.5, não reescreva totalmente 03/04
  5. Refazer estágio: Solicitação explícita para refazer um arquivo → reproduza o arquivo e marque o downstream conforme regra de propagação de invalidação (seção 6 de consistency.md)

Revisão de Roteiro Vivo: Rearranjo Local (Lição prática — 03 já foi totalmente reescrito duas vezes por causa disso)

A produção de vídeo com IA real não é uma linha reta: depois que o usuário vê as imagens, ele pode querer adicionar takes, remover uma linha, alterar um trecho do enredo. O congelamento do GATE1.5 trava o esqueleto da história e a lista de pontos da trama, não a tabela de storyboard — a tabela de storyboard é um documento vivo.

Quatro etapas do rearranjo local (mexa apenas na parte afetada):

  1. Altere a lista de pontos da trama: Adicione/remova/altere a linha correspondente, anote a data da revisão e a justificativa (pontos-chave das palavras originais do usuário) — esta é a única 'montante' que precisa ser mexida
  2. Julgue o escopo de impacto: Os novos pontos da trama afetam quais cenas/personagens/adereços? → A tabela de ancoragem 02 só adiciona entradas para novas entidades (âncoras existentes não mexem, só se alteradas, aí sim, propague a invalidação)
  3. Insira número de take, não renumerar: Use número de take estável (abaixo) para inserir novos takes, os números de take existentes nunca mudam — o conteúdo existente de 03/04 não é invalidado
  4. Escreva prompts apenas para takes novos/alterados: Adicione-os nas seções correspondentes de 03/04, anote a data da revisão; verifique os takes adjacentes com 'altere uma batida, leia três batidas consecutivas', não mexa no resto. Ao alterar prompts de takes existentes, as falas/número do take/duração de geração são campos congelados — copie as falas palavra por palavra do 01, após escrever, leia palavra por palavra e compare (regra rígida 4)

Regra de número de take estável (portão rígido): Uma vez atribuído, o número de take nunca é renumerado. Para inserção, use sufixo — entre S3 e S4, escreva S3a (ou adicione a linha 'S3a (adicionado v2)' na tabela de storyboard do 01), não mude S4 para S5. Motivo: renumerar faria com que a matriz de referência de ativos do 03, os segmentos do 04 e os nós já criados na tela/plataforma de geração ficassem todos desalinhados, custo real = reescrita total do 03. Takes descartados são marcados na tabela de storyboard como ~~S3b~~ (descartado v3) mantendo o número da linha, não exclua a linha.

Unidade de produção baseada em segmento (V2.9 — ritmo real de 'usuário narra um segmento, faz um segmento'): O rearranjo local é no nível do take; quando o usuário adiciona um segmento narrativo completo (narra um novo trecho de história → precisa de conjunto de imagens de situação → precisa de nó de vídeo → validação → próximo trecho), a unidade de produção é 'segmento' não 'take', siga o seguinte ciclo mínimo, não refaça GATE1.5, não renumerie completamente a tabela de storyboard:

  1. Inclusão do segmento na lista: Os pontos da trama do novo segmento são adicionados linha por linha na lista de pontos da trama do 01 (anote data da revisão + pontos-chave da narração do usuário), atribua número de segmento e número de take estável (sufixo)
  2. Verifique existentes: As cenas/personagens/adereços tocados pelo segmento primeiro verificam a matriz de ativos do 02 e 03 — âncoras e imagens de referência existentes são reutilizadas diretamente, apenas novas entidades adicionam entrada de âncora/geram nova imagem de ativo
  3. Produção autocontida dentro do segmento: Conjunto de imagens de situação do segmento (por nível L1-L4) → Prompt de segmento de vídeo (Esqueleto A) → Falas (copiadas palavra por palavra do 01) — conclua um ciclo e execute check.py --partial, se passar, corra automaticamente o próximo segmento; quando todos os segmentos (lotes) estiverem concluídos, relate uniformemente (resultados quantificados + resultado do check + itens não aprovados nomeados). Para imagens de referência não geradas, escreva PLAN-<ID> placeholder e produza normalmente (veja disciplina de parada E2), não pare para esperar a imagem
  4. Sincronização após validação do segmento: Validação aprovada → complete as linhas do segmento na tabela de storyboard do 01, adicione a seção do segmento em 03/04, mexa no 02 apenas quando houver novas entidades; a descrição do frame final é escrita no registro do segmento (âncora de conexão para o SCENE CONTEXT do próximo segmento)

Relação com os seis estágios: O sistema de segmentos não pula estágios, ele fatia os Stages 2-6 em segmentos — a ancoragem (02) e o esqueleto do roteiro (01 lista de pontos da trama) ainda são de nível de projeto, dentro do segmento, faça apenas as imagens/vídeo/falas/entradas de edição daquele segmento. Os primeiros takes ainda seguem 'primeiro produza o primeiro conjunto completo para validação do usuário antes de expandir'.

Registro de revisão: Cada rodada de revisão adiciona um registro de alteração no 01 (o que foi alterado/escopo de impacto (nº take·ponto da trama·estágio)/arquivos afetados/pontos-chave das palavras originais do usuário), não reescreva a seção de histórico — a própria trilha de revisão do 01 é a base para a recuperação de interrupção. Ponto de escrita único (V2.9): O registro de alteração só é escrito no 01; não repita o histórico de alterações no 00/02 — o 02 só altera o campo em si (atualização de entrada de âncora), o 00 só atualiza o estado narrativo quando o episódio é concluído. Escrever nos três lugares = baixa pesquisabilidade e certamente esquecerá de alterar um.

Lista de retorno de alterações do lado da geração (V3.7): Após alterar o prompt na tela/nó de geração, retorne para três lugares e verifique palavra por palavra — ① bloco de segmento correspondente no 04 ② Falas no 05 (se envolvido) ③ Tabela de storyboard no 01 (duração/conexão/registro de revisão); feche itens OPEN, vincule atualizações PLAN/REF. A escrita dupla manual é fácil de perder, após retornar, execute check.py --partial.

Projetos com Origem na Tela/Plataforma de Geração (Usuário Altera Direto na Ferramenta)

Ao usar uma tela estilo Toonflow para executar a geração, o usuário geralmente altera os prompts diretamente na tela, move nós, exclui nós — neste momento, a tela é a verdade do lado da execução, 01-06 são a fonte da decisão. Relação entre os dois:

  • Não busque sincronização em tempo real (testado: sincronizar apenas com 'sincronizar' é perseguir, e cada sincronização é um desperdício) → Mude para sincronização em lote atrasada: quando uma rodada de geração chegar a um ponto de pausa, sincronize uma vez, o conteúdo da sincronização é um 'cartão de resumo' (ID do nó + uma linha de estado + pontos de diferença do documento), não preencha de volta o texto completo palavra por palavra
  • Decisão de conflito: Se a tela e o documento forem inconsistentes e o usuário já finalizou na tela a tela prevalece, o documento registra a diferença e atualiza a decisão (não é reverter a tela para o documento)
  • Marca de finalização: O nó de 'salvar imagem finalizada separadamente para evitar contaminação' criado pelo usuário na tela é uma prática válida → a matriz de ativos do documento registra o ID do nó de finalização, não sobrescreva ao regenerar
  • ID do nó consulte apenas a tabela, não adivinhe (V3.7): A única fonte do ID do nó na tela é a tabela de referência do projeto (matriz de ativos 02/03, cartão de resumo da tela); o agente não deve inferir/fabricar IDs com base na memória ou similaridade. Se não estiver na tabela → Pare e consulte a tabela ou pergunte ao usuário, não conecte/opere IDs não registrados (testado: adivinhar o ID pode conectar o nó errado ou todo o lote ser executado silenciosamente)
  • Número ref = ordem de criação da conexão (correção V3.15): append geralmente apenas adiciona novos números (ref7/ref8), não bagunça a ordem existente — o prompt só precisa adicionar à tabela de ordem de imagens pendentes; apenas 'inserção no meio causando reordenação do ref existente' exclui todas as linhas de entrada e reconecta na ordem final. Independentemente de qual, a tabela de ordem de imagens pendentes do 04 deve ser alterada em sincronia, e verifique uma a uma {{ref N}} com a declaração de uso correspondente (teste na tela antiga v21/v22 inserção desalinhada)
  • Controle de versão ao reenviar texto completo na plataforma de geração (teste V3.9; setPrompt atual da tela): Se a plataforma de geração não tiver edição local, antes de cada reenvio, salve o prompt atual como um resumo de versão (número da versão + ponto de alteração) e escreva no registro de alteração do 01; após o reenvio, compare com o documento 04, é proibido confiar na memória do contexto para a versão atual (versão errada = retrabalho de todo o segmento). Após trocar de software de tela, esta disciplina é mantida, a operação específica é reescrita com base na nova ferramenta.
  • Acionamento de sincronização: Usuário diz 'sincronizar', ou uma rodada de geração termina, ou antes de entrar no Stage 5/6 — três pontos de acionamento, não sincronize no resto do tempo

Prioridade de teste de capacidade sobre registro travado (lição prática: o plano principal travado no GATE0 de 'saída direta de fala de vídeo H3 + auto-extração de timbre' falhou diretamente porque a versão gateway do H3 não suporta áudio): A lista de capacidades travada no GATE0 é base de planejamento, não garantia — a capacidade real disponível na ferramenta é a referência antes da geração; quando o plano principal falhar, mude para a rota alternativa (fala → sincronização cosyvoice) e registre o motivo da troca no 01/02, não repita a tentativa de capacidade já julgada não suportada. Transformação em ponto de verificação (V2.9): Ao travar o modelo no GATE0, anote o provedor/gateway (diferentes provedores do mesmo modelo podem ter capacidades diferentes — H3 generateAudio do moma vs. apiMart, um recusa, o outro aceita); antes da geração, teste as principais capacidades do provedor atual (saída direta de áudio/quantidade e tamanho de imagens de referência/limite de duração), diferenças de provedor já registradas consultam a seção 'Memorando de diferenças de provedor' de models.md, se o resultado do teste conflitar com o memorando, prevalece o teste atual e preencha de volta.

Disciplina de verificação de alteração de ponto único (altere uma batida, leia três batidas consecutivas): Após modificar qualquer take/batida, você deve reler uma batida antes e uma depois, verificando especificamente três coisas — posição do personagem (frase de posicionamento/MAPA DE LOCALIZAÇÃO ainda é válida?), estado do adereço na mão (no take anterior estava na mão esquerda, neste take não pode estar na direita), quem está presente (figurantes padrão 0 ainda é válido?). O estado espacial está na mente ao escrever, mas não está ao modificar — não reler consecutivamente resulta em teletransporte.

  • Antes de modificar, parafraseie para si mesmo (lição prática V2.9 + downgrade para autoevidência V3.0): Para microajustes de take (instruções do tipo alterar posição da câmera/plano/composição/direção de segurar), antes de modificar o prompt, primeiro parafraseie em uma frase sua compreensão da composição ('Entendo que: tomada de cima para baixo, ela está sentada ao lado dele no ombro, os dois não se tocam') e escreva no registro de alteração do 01; apenas quando acionar a lista de ambiguidade oral (rosto inteiro/perfil/levemente contra-plongée) e o contexto não puder resolver a ambiguidade, pergunte ao usuário. O custo de parafrasear uma frase ≈ 0, o custo de uma rodada de retrabalho = uma geração + uma espera — a paráfrase impede 95% dos desvios de entendimento antes de escrever, a ambiguidade real é elevada para pergunta.
  • Finalização de imagem de situação aciona releitura (V2.9 — transforma 'altere uma batida, leia três batidas consecutivas' de remediação a posteriori em ação padrão): Ao finalizar qualquer imagem de situação/imagem de primeiro frame (incluindo refinalização após alteração), você deve reler todos os blocos de takes de segmento de vídeo que a referenciam, verifique segmento por segmento se a descrição da cena é consistente com a nova imagem finalizada (pose/segurar/posição/vestuário) — blocos de takes inconsistentes são corrigidos imediatamente, não espere até que a geração falhe para descobrir.

Da mesma forma: Paisagem sonora também é uma instrução de ação — se a paisagem sonora escreve 'o sino estala no impacto', o vídeo realmente vai representar o impacto; alterar a imagem exige sincronização de três lugares (descrição da cena do bloco de take/AUDIO paisagem sonora/01 tabela de storyboard), alterar o corte do take exige ler o corte adjacente (posição é estado contínuo).

Escada de retorno para efeitos insatisfatórios (quando um take falha/qualidade baixa, tente em ordem): Antes de entrar na escada, verifique a gerabilidade (prompt-rules 0.7): Se a lista de sinais de falha for acionada (coreografia de mãos com mais de 3 etapas/palavras inferidas/ações negativas/dois sujeitos com força precisa no mesmo objeto) → primeiro mude a forma de realizar conforme os cinco métodos de reescrita, não mude o enredo

Habilidades Relacionadas