Communitygithub.com

atilla777/omr

Se usa al recopilar o revisar requisitos para un video OMR: discutir la idea del video, realizar una entrevista, elegir entre Remotion/Manim/híbrido y guardar el archivo requirements.md. Es propietario de los requisitos del video, no de entrevistas generales, investigación de contenido, guion gráfico, renderizado ni desarrollo del propio OMR.

¿Qué es omr?

Este skill guía al agente en la recopilación y definición de requisitos para un video del formato OMR (One Minute Review o similar). Su función principal es entrevistar al usuario para aclarar todos los aspectos necesarios (tema, audiencia, contenido, estilo visual, modo de producción) y documentarlos en un archivo `requirements.md` dentro de la subcarpeta del proyecto. El soporte es para entornos como Cursor o Claude Code que permiten cargar skills y dependencias del método `ris-port-op-interview`. El proceso comienza cargando el diálogo y la dependencia de entrevista, y luego guía al usuario a través de preguntas enfocadas un único tema por vez, manteniendo un árbol de decisiones actualizado para evitar redundancias y asegurar que se cubran todas las ramas esenciales. Finalmente, el skill evalúa si la información es suficiente para proceder a la siguiente fase (sin instalar motores de producción) y guarda el documento con todas las decisiones, orígenes y limitaciones, evitando duplicar entrevistas o handoffs innecesarios.

Compatible con~Claude Code~Codex CLI~Cursor✓OpenCode
npx skills add https://github.com/atilla777/omr/tree/HEAD/.opencode/skills/omr-requirements

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Requisitos del video OMR

Eres el propietario del resultado requirements.md de un video concreto. Comunícate en el idioma del usuario. Combina las decisiones temáticas a continuación y el método ris-port-op-interview en un solo diálogo: este skill determina la suficiencia y guarda el documento, mientras que la dependencia gestiona la investigación de decisiones y la entrevista.

Entradas y selección del proyecto

Al inicio del trabajo, carga omr-dialogue mediante skill, si aún no está cargado en el contexto actual. Aplica tanto a la selección de la subcarpeta como a la entrevista de contenido: la elección se realiza mediante question, las opciones de texto deben ir siempre numeradas. Si la dependencia no está disponible, informa y acuerda su conexión. El método ris-port-op-interview utiliza estas reglas de formato en el mismo diálogo.

Si existe reviews/requirements.md, léelo y ten en cuenta los problemas descritos al crear o modificar los requisitos. Si el archivo no existe, no hay observaciones previas de la revisión. No inicies la revisión por tu cuenta ni modifiques su informe: es una operación independiente. Cuando trabajes bajo un líder, devuélvele el resultado o las preguntas; el líder gestiona las transiciones.

  1. Lee los AGENTS.md aplicables, la solicitud y los materiales proporcionados disponibles. Ten en cuenta la carpeta actual, la ruta explícita del usuario y el requirements.md existente. No consideres la raíz del área de trabajo como cualquier directorio con .git: establece el contexto según las reglas del área y su estructura. No insertes rutas de la máquina del autor.
  2. Si OpenCode se ejecuta en una subcarpeta de un video, ese es el proyecto; no crees otra carpeta de video dentro de él. Si se ejecuta en la raíz del área y el proyecto no está especificado, primero sugiere elegir una subcarpeta existente o nombrar una nueva (una sola pregunta). No guardes los requisitos en la raíz de OMR. Crea la nueva subcarpeta explícitamente elegida dentro del área, sin un .git anidado; si la ruta es ambigua, aclárala.
  3. Antes de la entrevista de contenido, carga ris-port-op-interview mediante skill. Si no está disponible, nombra el bloqueador y acuerda su conexión; no presentes un cuestionario común como la ejecución de este método. No es necesario instalar motores aquí.
  4. Pasa al método el tema, los límites (decisiones para el video concreto), el siguiente resultado (requisitos suficientes), las respuestas conocidas con sus fuentes y su estado. El modo normal del método es completo dentro de estos límites; no declares la entrevista como limitada solo porque el video sea pequeño o queden pocas preguntas.

Trabajo temático

  • Primero, estudia lo conocido: la solicitud, las respuestas del diálogo actual, los requisitos y materiales existentes. No repitas respuestas conocidas. El documento es la fuente de las decisiones actuales, pero su existencia por sí sola no implica una aprobación independiente. En caso de contradicción, señala el conflicto de fuentes y aclara la decisión afectada.
  • Mantén un árbol de dependencias actualizado: por ejemplo, el objetivo y la audiencia influyen en la profundidad del contenido; la plataforma, en el formato; la locución, en la obtención de la voz y el tiempo. Elige la siguiente pregunta sustancial según el frente de este árbol, no según un cuestionario. Una pregunta sobre una decisión por mensaje, luego espera la respuesta. Si usas question, transmite solo un elemento questions; no escondas varias decisiones independientes en una sola pregunta larga. Un paquete de preguntas solo está permitido si el usuario lo solicita explícitamente.
  • Áreas de discusión: tema, objetivo y efecto esperado, audiencia y sus conocimientos, contenido obligatorio y excluido, estructura deseada, estilo visual, duración, plataforma/relación de aspecto/resolución/FPS, idioma del texto en pantalla, sonido, recursos y limitaciones. Esto no es una lista de preguntas obligatorias: ten en cuenta lo ya conocido, cierra las ramas irrelevantes con su razón y deja los detalles no esenciales para las siguientes fases dentro de límites de libertad explícitamente indicados.
  • Para las decisiones sustanciales desconocidas, ofrece opciones fundamentadas y, si hay motivos, una recomendación. Distingue una propuesta de una decisión adoptada: el silencio, la repetición de la propuesta o el acuerdo con un punto adyacente no constituyen adopción.
  • Recomienda y acuerda un modo: Remotion para composición, títulos, medios y animaciones React; Manim independiente para animaciones matemáticas/geométricas; híbrido para fragmentos de Manim en un montaje de Remotion. Explica la elección aplicada al video sin instalar motores. No vuelvas a preguntar por un modo que el usuario ya haya elegido explícitamente. Si hay un conflicto importante entre los requisitos y el modo, discútelo.
  • Si se necesita locución, establece la fuente (grabación ya existente, grabación del usuario, generación), el idioma y las propiedades esenciales de la voz o la voz concreta si es importante. No prometas disponibilidad de TTS, servicio de pago, licencia o voz sin verificación. Si falta algún acceso, documéntalo y acuerda la forma de obtenerlo, sin solicitar secretos en el documento. Determina por separado la música/los efectos o su ausencia.
  • Documenta los requisitos esenciales de imágenes, videos, fuentes y otros recursos, las rutas/enlaces proporcionados y las limitaciones conocidas. No empieces a recopilar contenido, descargar ni generar medios de producción.

Suficiencia y guardado

Finaliza cuando se hayan explorado las ramas sustanciales dentro de los límites del video y se pueda recopilar contenido, escribir el guion y planificar la producción sin tener que adivinar decisiones importantes. El modo debe estar acordado; el objetivo, la audiencia, el contenido, el diseño, la duración/formato, el sonido y las restricciones de recursos deben estar definidos o tener una libertad explícitamente permitida por el usuario. No exijas una aprobación separada del documento ni introduzcas un estado obligatorio de "aprobado".

Usa el handoff del método como entrada para verificar la suficiencia. Tú eres responsable de consolidar las decisiones, verificar y escribir el requirements.md; la prohibición de depender del guardado de la especificación por defecto no anula esta escritura explícitamente encomendada. No dupliques en la respuesta una segunda entrevista independiente ni un handoff enorme; guarda las decisiones importantes, sus fuentes, las preguntas abiertas y su impacto en el propio documento.

El documento debe ser comprensible para la siguiente sesión sin acceso al chat anterior. Adapta la estructura, conservando la siguiente información:

  • tema/objetivo/audiencia; contenido, exclusiones y restricciones estructurales;
  • modo elegido y fundamento; duración y formato técnico;
  • diseño, idioma, sonido/locución y método de obtención de la voz; recursos y limitaciones;
  • origen de las decisiones (solicitud, respuestas de esta sesión, documentos/enlaces disponibles), separación de hechos y decisiones adoptadas de las propuestas;
  • preguntas aplazadas/no conocidas, libertad permitida para las siguientes fases e impacto concreto de las lagunas en la preparación, si las hubiera.

Si hay una laguna sustancial, continúa con una sola pregunta. Si la respuesta no está disponible ahora, informa del bloqueador exacto; si se solicita guardar un estado intermedio, registra un resultado incompleto con indicación explícita de lo que falta, sin llamarlo requisitos suficientes. Si no tienes permiso de escritura, proporciona el texto no guardado e indica la limitación.

En una ejecución repetida, primero lee el archivo existente, modifica solo lo que se te ha encomendado, conservando el resto del trabajo. No renegocies todo el video por una modificación local. No actualices automáticamente el contenido, el guion ni el video.

Después de guardar, vuelve a leer el archivo: comprueba que no haya contradicciones, decisiones no confirmadas, limitaciones perdidas, enlaces no transferibles al chat; verifica que la ruta y la suficiencia sean correctas. Informa de la ruta real, un breve resumen y las preguntas abiertas importantes. Detente. No inicies la siguiente fase. Solo puedes mencionar el comando de la siguiente fase, verificando que realmente esté implementado en esta instalación.

En toda la fase, no instales Remotion, Manim ni otras dependencias de producción, no crees archivos package, fuentes de escenas, renderizados ni un árbol vacío del proyecto futuro. Basta con la subcarpeta elegida y requirements.md.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Skills relacionados