ELX EzVideoEdit

O que ELX EzVideoEdit faz?

Esta Skill funciona com o ELX Workstation, não é um processador de vídeo independente. O bundle-location.json após a instalação aponta para o workstation real; a CLI no código-fonte localiza automaticamente o diretório raiz, ou pode ser especificada com EZVIDEOEDIT_ROOT. Na primeira utilização, leia as Configurações da Máquina. Modelos locais, Python, permissões de acesso MCP e serviços de texto devem ser configurados pelo usuário; não herdam autorizações ou credenciais do autor.

Primeira Fase: Produção e Entrega

A execução padrão vai até a entrega local. O usuário escolhe o material, o diretório de saída e o método de revisão manual das legendas para este lote; quando não houver escolha, pergunta se deseja pular ou modificar manualmente. Se já estiver claro que este lote será pulado, lê o resumo fresco de cada vídeo e registra skip, sem repetir a pergunta nem afirmar que a revisão manual foi aprovada. Não considere contas de plataforma ou conexões de navegador como condição para conclusão local.

1. Execute node .agents/skills/elx-ezvideoedit/scripts/cli.mjs help e use status para verificar as capacidades reais. Inicie ou reutilize serviços via launch. As tarefas são escritas através do mesmo serviço, sem modificar task.json diretamente. Veja os campos detalhados em Interface Local.
2. Através de tools/list e get_status, descubra a capacidade native-production/1; as versões oficiais 0.9.1 e a já verificada 0.9.0 usam o schema real. Verifique primeiro a instância do mesmo perfil; se necessário, use node packaging/setup.mjs native-open para abrir a GUI e depois native-connect; GUI e stdio compartilham o perfil. Quando faltarem modelos, APIs ou permissões, informe o local das configurações nativas e deixe o usuário tratar, sem alterar políticas para contornar.
3. A cadeia de qualidade é: MOSS para transcrição principal, FireRed para linha do tempo em nível de caractere, Qwen3-ASR para verificação independente, usando modelos e Python já presentes na máquina; a pontuação inteligente e revisão usam serviços de texto salvos nativamente. Relate separadamente a execução real, o reuso de cache e os downgrades; não considere concluído apenas por rótulos de configuração. A correção de gagueira nas legendas não equivale à remoção de áudio/vídeo.
4. Use native-start para produção serial, native-state para consulta, native-resume para retomar. Ferramentas independentes usam native-operation. Após AI preview, aplique com o mesmo job_id, sem reenviar para fora. Em caso de timeout ou resultado incerto, primeiro verifique jobs/attempts antigos; só retome quando configuration_required estiver claro, após o usuário concluir a configuração, sem reenviar cegamente.
5. Escopo nativo scope=current permite apenas o projeto atual; criar ou abrir outros projetos requer escopo library; capacidades independentes executam com suas respectivas permissões. A versão 0.9.x não chama as interfaces de autorização contínua ou token em lote da antiga 0.8.7, nem adiciona batch_token a apply_plan/export_subtitles oficiais.
6. Após save_project oficial, exporte o vídeo e o SRT oficial, verificando o snapshot do mesmo projeto. native-adopt só vincula projetos de origem com SHA do material consistente. review-inspect lê o número real de sugestões; se sem permissão, mantenha contagem desconhecida; quando autorizado a pular, use a signature atual para salvar review-choice. Modificações manuais são salvas pelo usuário no programa nativo; depois review-finish apenas reexporta vídeo/SRT, sem reexecutar reconhecimento para sobrescrever alterações manuais. verification_required usa review-recover para verificar jobs antigos, sem reiniciar.
7. Downgrade na linha do tempo segue as proteções existentes do serviço. Pular a verificação manual não equivale a ignorar falhas, erros desconhecidos ou falta de evidência temporal. Só salve o escopo de proteção quando explicitamente autorizado a continuar conservadoramente; preserve-review é usado apenas para revisão de texto já concluída mas parcial, com número de erros solicitado igual a 0, preservando o texto original e os intervalos protegidos do lote inteiro, sem adotar sugestões desse lote, sem reenviar, e mantendo o recibo parcial.
8. Baseado na transcrição real, gere exatamente 5 títulos de estilos diferentes, 3 descrições diferentes com no máximo 50 caracteres cada, e tags independentes. As capas devem ser três imagens reais nos formatos 16:9, 4:3 e 3:4, verificando texto, conteúdo e proporção uma a uma, sem esticar. Pode recomendar combinações, mas não pode forjar que o usuário já selecionou.

Avance continuamente dentro do escopo aprovado; novas remessas externas, custos, diretórios ou mudanças de permissão devem ser confirmadas conforme a solicitação do usuário atual. Ao pausar, preserve o vídeo original, o projeto, a saída e os recibos; ao retomar, primeiro faça uma verificação somente leitura. Por padrão, execute em série na conversa atual; só delegue a novas conversas ou subagentes quando o usuário solicitar explicitamente; o modelo é escolhido pelo usuário e pelo host. O botão "Entregar ao Codex" na web apenas salva tarefas pendentes, não significa que o host já executou.

Entrega em Pastas

Cada vídeo gera uma pasta <NomeOriginal>_Entrega com os seguintes arquivos diretamente na raiz: video_final_legendado.mp4, video_original (com nome original), legendas.srt, texto_publicacao.txt, capa_16x9.png, capa_4x3.png, capa_3x4.png, instrucoes_entrega.txt. Apenas o projeto editável e as dependências reais vão para a subpasta "projeto".

• Após verificação do material, mova o único material original de volta para seu nome original, verificando SHA e caminho absoluto antes e depois, atualizando e validando as referências do projeto. Não copie para fingir ser o vídeo original da entrega; se houver cópias duplicadas, liste caminhos, quantidade, tamanho e impacto; após obter confirmação de exclusão, processe sem sobrescrever o único original.
• O projeto deve corresponder ao mesmo snapshot do vídeo final/SRT e as dependências devem estar disponíveis; inclua apenas materiais realmente referenciados, sem copiar o cache inteiro ou projetos históricos. As instruções de entrega consolidam o número de cortes, lembretes de modelo/legendas e conclusões da validação; o recibo completo fica no workstation.
• scripts/package-stage1.py --help é o ponto de entrada de empacotamento simplificado; a tarefa salva pelo serviço de entrada, caminhos do texto e capas, e o vídeo original é movido do mesmo disco que original-root. Em caso de disco diferente ou conflito de nomes, pare; não faça cópia implícita seguida de exclusão. O import do workstation ainda copia materiais de trabalho; não é permitido excluir cópias de trabalho com base nisso.
• Somente considere a entrega completa após verificar material, resumo, timecodes, proporções das imagens e dependências do projeto. Se não houver candidato para corte, reporte 0 real, não finja remoção de áudio/vídeo. Atualizações de pacotes devem primeiro ser validadas, preservando modificações e histórico do usuário, sem sobrescrever diretamente.

Segunda Fase: Upload Opcional

Por padrão, o usuário usa o MultiPost existente ou a entrada normal da plataforma. Ao final da primeira fase, forneça o caminho da entrega e o texto; se o usuário ainda não declarou preferência de upload, lembre que pode fazer manualmente; se já declarou que não fará upload, encerre sem repetir a pergunta. Veja mais em Limites do Upload Opcional.

Somente quando o usuário solicitar explicitamente que o Agent acione, use a entrada normal dos plugins existentes, verifique a conta real e a autorização, e pare antes da publicação final. Se o plugin, login, captcha ou controle falhar, preserve o estado e entregue ao usuário; não use Computer Use automático, injeção ou modificação de plugins. Confirme antes de pagamento, registro, publicação, envio de mensagens ou alteração de permissões de conta. O workstation preparar o recibo não significa que o upload ou a publicação foram bem-sucedidos.