WesleyQDev/rooster-edit

RoosterEdit

O RoosterEdit é um estúdio de vídeo para agentes. Ele não substitui o Remotion, HyperFrames ou FFmpeg; ele decide o que fazer, organiza os ativos, escreve o plano, conduz o motor escolhido, revisa o resultado e entrega o pacote.

A regra mais importante: não renderize antes que o plano e a prévia sejam aprovados, a menos que o usuário peça explicitamente para não parar. Renderizar é a parte mais barata do pipeline e o erro mais caro para desfazer.

Executando a CLI

Esta habilidade envia sua CLI em scripts/rooster.mjs relativo ao diretório base da habilidade. Execute-a a partir do diretório do projeto do usuário, resolvendo o script em relação à base da habilidade. Nos exemplos abaixo, <skill> significa esse diretório base:

node "<skill>/scripts/rooster.mjs" doctor --json

Não crie um diretório scripts/ no projeto do usuário apenas para satisfazer o comando. O workspace (rooster/) pertence ao projeto; a CLI pertence à habilidade. Se o diretório de trabalho do shell for o diretório da habilidade, a CLI criará o workspace no lugar errado.

Onde instalar a habilidade

Quando o usuário pedir para instalar o RoosterEdit, pergunte primeiro se a instalação deve ser local ao projeto (recomendado) ou global. Use a pasta de habilidades que o harness atual realmente lê; não presuma OpenCode.

• Local: a pasta de habilidades do projeto do harness mais rooster-edit (por exemplo .opencode/skills, .claude/skills ou .agents/skills). Recomendado porque a versão fica com o projeto e não pode surpreender outros trabalhos.
• Global: a pasta de habilidades global do harness mais rooster-edit (por exemplo ~/.config/opencode/skills ou ~/.claude/skills). Use apenas quando o usuário quiser o RoosterEdit em todos os projetos da máquina.

Se você não conseguir determinar as pastas do harness, inspecione seus caminhos de descoberta de habilidades ou pergunte ao usuário. Aguarde a resposta antes de clonar. Esta escolha é sobre onde a habilidade vive, não onde o workspace de vídeo vive (./rooster).

Relatórios

As respostas de fim de tarefa são curtas por padrão: 5 a 10 linhas ou uma tabela compacta. Inclua apenas o que o usuário precisa para agir:

• o que foi feito ou encontrado;
• os caminhos ou links para o resultado;
• o que está faltando ou bloqueado, se houver;
• uma próxima pergunta clara.

Não repita o briefing, cole logs, liste todos os comandos ou explique toda a habilidade, a menos que o usuário peça. Coloque detalhes em arquivos do workspace ou vincule os documentos de referência. Um plano, relatório de QA ou pacote de entrega pode ser mais longo apenas porque o usuário precisa revisar seu conteúdo.

Instalação e configuração do workspace são etapas separadas. Após instalar e executar doctor, não inicie a integração ou escreva um guia. Resuma o ambiente em algumas linhas e pergunte se o usuário deseja configurar o workspace agora. Aguarde um sim antes de criar rooster/ ou um canal.

Atualizações de progresso

Use um marcador de etapa compacto nas atualizações de status e em cada ponto de aprovação. Mantenha um rastreador de 8 etapas para o projeto:

1. Ambiente e workspace
2. Briefing e coleta
3. Ativos e transcrição
4. Plano de edição
5. Storyboard e timeline
6. Build do motor
7. Prévia e QA
8. Renderização e entrega

Exemplos:

• Etapa 3/8 — Transcrição concluída. 42 trechos, 10:12 de duração.
• Etapa 4/8 — Plano pronto em edit/plan.html. Posso seguir com a timeline?
• Etapa 6/8 — Build concluído. Posso abrir a prévia e rodar o QA?
• Etapa 8/8 — Prévia aprovada. Posso renderizar o final?

Pule etapas que não se aplicam e diga o porquê. Não imprima a lista de verificação completa em cada mensagem; mostre a etapa atual, o que mudou e o próximo ponto de aprovação. Não combine timeline e renderização final em uma única aprovação: prévia e QA ficam entre elas.

Execução orientada a subagente

O agente principal é o diretor, não o trabalhador. Ele conversa com o usuário, é dono do briefing e das decisões, executa os pontos de aprovação e examina os quadros finais. O trabalho pesado vai para um subagente de estágio: análise de transcrição, pesquisa, rascunhos de script, rascunhos de plano, estilo e storyboard, build e correções, varreduras de QA, renderização e empacotamento. Cada subagente tem seu próprio contexto, que é descartado quando o estágio termina, para que o material bruto nunca se acumule no encadeamento principal.

Delegue por padrão sempre que o harness tiver uma ferramenta de subagente. Mantenha o estágio inline quando for um comando barato, quando for a própria conversa (coleta, aprovações) ou quando for o julgamento visual final.

Estágio	Subagente	Agente principal recebe
Briefing	producer	briefing de um parágrafo + perguntas em aberto
Pesquisa	researcher	5 descobertas + fontes + sinalizadores de licença
Transcrição	transcript-analyst	duração, tópicos, 10–20 batidas, sinalizadores
Script	scriptwriter	gancho + resumo de batidas
Plano	editor	resumo do plano + riscos
Estilo/storyboard	art-director	tokens + contagem de cenas + necessidades de ativos
Timeline	editor	matemática de duração + marcadores
Áudio	audio-director	decisões de voz/música/mix
Build	engineer	status + caminhos de artefatos + bloqueadores
QA	qa	veredito + principais problemas + caminhos de quadros
Render	engineer	caminho final + estatísticas de prova

Invoque com um prompt curto: caminho do arquivo de função, caminho do projeto, uma frase de tarefa, caminhos de entrada, restrições. Passe caminhos, nunca o briefing, transcrição, logs ou conteúdo do plano. Se a entrada for a própria conversa, escreva as respostas em work/intake.md primeiro. Peça o handoff descrito em references/subagents.md e nada mais. Use o agente de propósito geral ou de trabalho do harness para estágios que escrevem arquivos ou executam comandos; um tipo somente leitura ou de pesquisa é adequado para pesquisa. Isso é uma capacidade, não um nome de ferramenta: se o harness não puder iniciar um novo agente com acesso a arquivos e comandos, ou uma invocação falhar duas vezes, execute o estágio inline e mantenha os limites de arquivo.

O handoff é a única coisa que entra no contexto principal:

status: ok | needs-decision | blocked
artifacts: paths that exist
summary: <= 5 lines
decisions: what the main agent must confirm
blockers: what stops the stage
next: next stage or exact question

O agente principal pode ler o briefing, script, estilo, review.md e handoffs, e pode visualizar plan.html e 3–5 quadros. Ele não deve ler a transcrição bruta, o JSON completo do plano, o código gerado, os logs de build/renderização ou uma folha de contato com dezenas de quadros. Se um detalhe estiver faltando, envie um acompanhamento para o mesmo subagente em vez de abrir o arquivo bruto.

Nada aqui é uma dependência. Os artefatos e pontos de aprovação são os mesmos quando um estágio é executado inline; você perde o isolamento de contexto, não o fluxo de trabalho.

Os pontos de aprovação nunca são transferidos para um subagente. O subagente propõe; o usuário e o agente principal decidem.

Primeira execução após a instalação

Se o workspace ainda não existir, faça uma integração curta antes de criar qualquer projeto.

Primeiro pergunte: "Quer configurar o workspace agora?" (ou "Shall we set up the workspace now?"). Explique em uma linha que isso cria rooster/ e o primeiro canal. Se a resposta for não, pare e não crie nada.

Se a resposta for sim:

1. Use ./rooster por padrão. Não pergunte "onde o workspace vive" a menos que o usuário queira um caminho personalizado.
2. Faça uma pergunta: "O que esse canal vai produzir? Uma frase basta." Use a resposta e a conversa para inferir o nome do canal, idioma, formato, fonte, perfil, ativos, motor, autonomia e voz. Não pergunte todos os doze campos do canal e não peça uma duração.
3. Mostre os padrões inferidos em uma linha compacta e pergunte "Está bom ou quer ajustar algo?" Faça uma pergunta de acompanhamento apenas quando um campo for genuinamente ambíguo, como a plataforma ou se a fonte é filmagem real.
4. Após a confirmação, execute init, depois channel new <id> ... com as respostas. Mostre um resumo curto e pare.

Duração não é um padrão de canal: pertence a cada projeto e é escolhida quando o vídeo é criado. A configuração completa de doze campos é um caminho avançado opcional. Se o usuário pedir para personalizar tudo, pergunte em grupos de no máximo três, nunca todos de uma vez.

Um canal é o grupo estável para uma marca, público ou operação (por exemplo "EN Tech" ou "PT Criador"). Ele possui os padrões criativos: idioma, formato, perfil, política de ativos, motor, autonomia e voz. Cada projeto pertence a um canal e pode substituir qualquer um desses padrões. Duração é por projeto, não um padrão de canal.

Não comece um vídeo na mesma rodada, a menos que o usuário peça explicitamente. Leia references/onboarding.md para as perguntas exatas, padrões e comandos. Leia references/assets.md antes de baixar ou gerar qualquer ativo.

Caminho rápido: o fluxo de trabalho de vídeo em 6 etapas

Quando o usuário quiser a rota mais simples de filmagem bruta para um vídeo finalizado, siga as mesmas seis etapas do fluxo de trabalho de referência, adaptadas ao workspace do RoosterEdit:

1. Prepare a máquina — FFmpeg, Node.js LTS, Python 3, HyperFrames e Whisper (ou Parakeet/whisper.cpp do HyperFrames). Pergunte antes de instalar qualquer coisa.
2. Crie ou resolva o projeto — rooster new ...; mídia bruta vai para assets/source/.
3. Escreva o guia de estilo — art-director escreve style.md e resolve o perfil. Execute styleproof <slug> e aprove as três amostras de quadros antes de planejar.
4. Transcreva e planeje — transcript-analyst escreve edit/transcript.json, edit/digest.md e edit/analysis.json; editor escreve edit/plan.json a partir da análise e style.md. Mostre plan.html com contexto de transcrição e aguarde aprovação.
5. Crie os elementos visuais — engineer constrói letreiros, gráficos, listas, zooms, b-roll, lower thirds, música e SFX quando o estilo do canal exigir. Um rascunho apenas de cortes não é um vídeo finalizado, a menos que o usuário tenha pedido explicitamente um corte limpo.
6. Monte, revise, exporte — engineer executa build para gerar o projeto HyperFrames ou Remotion a partir do plano aprovado; use --sample 3 antes do build completo. qa inspeciona preview/index.html e os quadros, então engineer renderiza para renders/; export escreve um handoff EDL/FCPXML quando o usuário quiser DaVinci ou Premiere.

Leia references/video-pipeline.md para os comandos exatos e o mapeamento das pastas do vídeo de referência para as nossas. O resto desta habilidade é o modo estúdio mais amplo; o caminho rápido é o padrão para trabalhos de vídeo único.

Princípios operacionais

• Direcione antes de gerar. Um briefing claro, script e lista de tomadas economizam mais tempo do que qualquer ajuste de prompt. Gaste a primeira parte do trabalho entendendo o vídeo.
• Inspecione, não presuma. Leia os arquivos, examine a mídia, olhe os quadros e verifique as ferramentas. Nunca afirme que uma renderização ou ativo existe porque o código parece correto.
• Mantenha a edição editável. Prefira cenas nomeadas, variáveis e componentes legíveis em vez de scripts únicos. O usuário deve ser capaz de alterar uma cor, uma linha ou um clipe sem reescrever o projeto.
• Revise com os olhos. Use a prévia do navegador, capturas de tela ou stills renderizados para julgar composição, ritmo e legendas. Apenas revisão de código não é suficiente.
• Respeite a proveniência. Registre de onde veio cada ativo e sua licença. Um vídeo bonito com uma faixa não licenciada é um passivo.
• Degrade graciosamente. O harness pode não ter subagentes, navegador, Node, FFmpeg ou TTS. Ofereça o melhor caminho disponível e diga o que está faltando.
• Delegue os estágios pesados. O agente principal dirige; subagentes de estágio fazem o trabalho pesado e retornam um handoff curto. Transcrições, logs de build, código gerado e varreduras de QA não devem passar pelo contexto principal. Leia references/subagents.md.
• Relate curto. Termine cada tarefa com o resultado, os caminhos e uma próxima pergunta. Não narre todo o processo nem despeje comandos, a menos que o usuário peça.
• Finalize a camada criativa. Apenas cortes não são um vídeo. Planeje sobreposições, b-roll, música, SFX ou legendas, a menos que o usuário tenha pedido explicitamente um corte limpo.
• Pergunte quando estiver incerto. Se uma escolha mudar o corte, a aparência, o áudio ou o custo, pergunte na Etapa X/8 atual. Não adivinhe silenciosamente.
• Proteja o contexto. O trabalho com vídeo consome muitos tokens. Redirecione logs do motor para arquivos, leia apenas o final, use digest em vez da transcrição completa e inspecione alguns quadros-chave em vez de todos os quadros. Leia references/token-discipline.md.

Etapa 0 - Encontre o workspace

Procure por um diretório rooster/ no projeto atual primeiro, depois use ROOSTER_WORKSPACE se estiver definido. O padrão é ./rooster; apenas pergunte por um caminho personalizado quando o usuário quiser um.

Se nenhum existir e o usuário já tiver pedido para fazer um vídeo, criar o workspace está implícito; execute:

node "<skill>/scripts/rooster.mjs" init

Se o usuário acabou de instalar a habilidade ou está apenas explorando, não a crie silenciosamente: siga "Primeira execução após a instalação" e pergunte primeiro.

O workspace é onde canais, projetos, perfis e a biblioteca de ativos vivem. Mantenha-o fora do diretório da habilidade; a habilidade é reutilizável, o workspace pertence ao projeto de vídeo do usuário.

Se o workspace existir, mas não tiver canal, crie um antes de criar um projeto. Cada projeto pertence a um canal; um canal default cobre vídeos avulsos.

Se o usuário estiver apenas fazendo uma pergunta ou explorando uma ideia, responda sem criar um workspace. Uma pergunta não é um pedido para construir.

Etapa 1 — Verifique as capacidades

Execute:

node "<skill>/scripts/rooster.mjs" doctor --json

Isso relata Node, npm, Python, FFmpeg, FFprobe, Git, GPU, motores detectados, provedores de TTS, yt-dlp, Whisper e a CLI do HyperFrames. O próprio harness sabe se subagentes e um navegador estão disponíveis; combine esse conhecimento com a saída da CLI. Para custos, leia docs/COSTS.md; nunca chame um provedor pago sem permissão explícita.

Leia references/harness.md quando algo estiver faltando. A versão resumida:

• Sem Node: use FFmpeg diretamente para cortes e áudio, mas não pode executar HyperFrames ou Remotion.
• Sem FFmpeg: ainda pode planejar, escrever script e fazer storyboard, mas não pode sondar ou renderizar localmente.
• Sem navegador: renderize stills ou quadros e inspecione-os como imagens.
• Sem TTS: use a voz do usuário, apenas legendas, ou um [truncado para tradução]