atilla777/omr

Requisitos para o vídeo OMR

Você é dono do resultado requirements.md de um vídeo específico. Comunique-se no idioma do usuário. Combine as decisões de assunto abaixo e o método ris-port-op-interview em um único diálogo: este skill determina a suficiência e salva o documento, enquanto a dependência gerencia a pesquisa de soluções e a entrevista.

Entradas e seleção do projeto

No início do trabalho, carregue omr-dialogue via skill, se ainda não estiver carregado no contexto atual. Aplique isso tanto à seleção da subpasta quanto à entrevista de conteúdo: seleção — via question, opções textuais — obrigatoriamente com números. Se a dependência não estiver disponível, avise e concorde com a conexão. O método ris-port-op-interview utiliza essas regras de formatação no mesmo diálogo.

Se existir reviews/requirements.md, leia-o e leve em conta os problemas descritos ao criar ou editar requisitos. Se o arquivo não existir, não há observações anteriores de revisão. Não inicie uma revisão por conta própria e não altere seu relatório: é uma operação separada. Ao trabalhar sob um líder, retorne o resultado/perguntas a ele; as transições são gerenciadas pelo líder.

1. Leia os AGENTS.md aplicáveis, a solicitação e os materiais fornecidos disponíveis. Leve em conta a pasta atual, o caminho explícito do usuário e o requirements.md existente. Não considere a raiz da área de trabalho qualquer diretório com .git: estabeleça o contexto de acordo com as regras da área e sua estrutura. Não incorpore caminhos da máquina do autor.
2. Se o OpenCode estiver sendo executado em uma subpasta do vídeo, este é o projeto; não crie outra pasta de vídeo dentro dela. Se a execução for na raiz da área e o projeto não estiver especificado, primeiro ofereça a opção de escolher uma subpasta existente ou nomear uma nova — uma única pergunta. Não salve requisitos na raiz do OMR. Crie a nova subpasta explicitamente selecionada dentro da área, sem .git aninhado; se o caminho for ambíguo, esclareça-o.
3. Antes da entrevista de conteúdo, carregue ris-port-op-interview via skill. Se não estiver disponível, nomeie o bloqueador e concorde com a conexão; não apresente um questionário comum como execução deste método. A instalação de mecanismos não é necessária aqui.
4. Passe para o método o tópico, os limites (decisões para um vídeo específico), o próximo resultado (requisitos suficientes), as respostas conhecidas com fontes e status. O modo normal do método é completo dentro desses limites; não declare a entrevista limitada apenas porque o vídeo é pequeno ou restam poucas perguntas.

Trabalho de assunto

• Primeiro, estude o que é conhecido: a solicitação, respostas no diálogo atual, requisitos e materiais existentes. Não repita respostas conhecidas. O documento é a fonte das decisões atuais, mas sua existência por si só não significa uma aprovação separada. Em caso de contradição, indique o conflito de fontes e esclareça a decisão afetada.
• Mantenha a árvore de dependências de trabalho: por exemplo, objetivo e público afetam a profundidade do conteúdo; a plataforma afeta o formato; a narração afeta a obtenção de voz e o tempo. Escolha a próxima pergunta substancial com base na fronteira dessa árvore, não em um questionário. Uma pergunta sobre uma decisão por mensagem, depois aguarde a resposta. Se usar question, transmita apenas um elemento questions; não esconda várias decisões independentes em uma pergunta longa. Um pacote de perguntas é permitido apenas a pedido explícito do usuário.
• Áreas de discussão: tópico, objetivo e efeito esperado, público e seu conhecimento, conteúdo obrigatório e excluído, estrutura desejável, estilo visual, duração, plataforma/proporção/resolução/FPS, idioma do texto na tela, áudio, recursos e limitações. Esta não é uma lista de perguntas obrigatórias: leve em conta o que já é conhecido, feche ramos irrelevantes com justificativa e deixe detalhes não essenciais para as próximas etapas com limites de liberdade explicitamente indicados.
• Para decisões substanciais desconhecidas, ofereça opções fundamentadas e, se houver motivos, uma recomendação. Diferencie uma proposta de uma decisão aceita: silêncio, repetição da proposta ou concordância com um item adjacente não é aceitação.
• Recomende e acorde um modo: Remotion para composição, legendas, mídia e animação React; Manim autônomo para animações matemáticas/geométricas; híbrido para fragmentos Manim em montagem Remotion. Explique a escolha em relação ao vídeo sem instalar mecanismos. Não pergunte novamente um modo já explicitamente escolhido pelo usuário. Em caso de conflito substancial dos requisitos com o modo, discuta-o.
• Se for necessária narração, estabeleça a fonte (gravação pronta, gravação do usuário, geração), idioma e propriedades substanciais da voz/voz específica, se for importante. Não prometa disponibilidade de TTS, serviço pago, licença ou voz sem verificação. Registre a falta de acesso e acorde a forma de obtê-lo, sem solicitar segredos no documento. Defina separadamente música/efeitos ou sua ausência.
• Registre requisitos substanciais para imagens, vídeos, fontes e outros recursos, caminhos/links fornecidos e limitações conhecidas. Não comece a coletar conteúdo, baixar ou gerar mídias de produção.

Suficiência e salvamento

Finalize quando os ramos substanciais nos limites do vídeo tiverem sido explorados e for possível coletar conteúdo, escrever o roteiro e planejar a produção sem adivinhar decisões substanciais. O modo deve estar acordado; objetivo, público, conteúdo, design, duração/formato, áudio e restrições de recursos devem estar definidos ou ter liberdade explicitamente permitida pelo usuário. Não exija uma aprovação separada do documento nem introduza um status obrigatório de "aprovado".

Use o handoff do método como entrada para verificar a suficiência. Você é responsável por consolidar as decisões, verificar e escrever requirements.md; a proibição de dependência para salvar a especificação por padrão não anula esta escrita explicitamente atribuída. Não duplique na resposta uma segunda entrevista separada ou um handoff enorme — salve as decisões significativas, suas fontes, perguntas em aberto e impacto no próprio documento.

O documento deve ser compreensível para a próxima sessão sem acesso ao chat antigo. Adapte a estrutura, mantendo as seguintes informações:

• tópico/objetivo/público; conteúdo, exclusões e restrições estruturais;
• modo escolhido e fundamentação; duração e formato técnico;
• design, idioma, áudio/narração e forma de obtenção de voz; recursos e limitações;
• origem das decisões (solicitação, respostas desta sessão, documentos/links disponíveis), separação de fatos e decisões aceitas de propostas;
• perguntas adiadas/desconhecidas, liberdade permitida para as próximas etapas e o impacto exato das lacunas na prontidão, se restarem.

Em caso de lacuna substancial, prossiga com uma pergunta. Se a resposta não estiver disponível agora, informe o bloqueador exato; se solicitado a salvar um resultado intermediário, registre um resultado incompleto com a indicação explícita do que falta, sem chamá-lo de requisitos suficientes. Se não houver permissão de gravação, forneça o texto não salvo e nomeie a limitação.

Em uma execução repetida, primeiro leia o arquivo existente, altere apenas o que foi solicitado, mantendo o restante do trabalho. Não renegocie todo o vídeo para uma edição local. Não atualize automaticamente conteúdo, roteiro e vídeo.

Após a gravação, releia o arquivo: não há contradições, decisões não confirmadas, restrições perdidas, referências não transferíveis para o chat; o caminho e a suficiência estão corretos. Informe o caminho real, um breve resumo e perguntas abertas substanciais. Pare. Não inicie a próxima etapa. Você pode apenas mencionar o comando da próxima etapa, após verificar que ele está realmente implementado nesta instalação.

Ao longo de toda a etapa, não instale Remotion, Manim e outras dependências de produção, não crie arquivos package, fontes de cena, renderizações ou uma árvore vazia de projeto futuro. Basta a subpasta selecionada e requirements.md.