WesleyQDev/rooster-edit

RoosterEdit

RoosterEdit es un estudio de video para agentes. No reemplaza a Remotion, HyperFrames o FFmpeg; decide qué hacer, organiza los activos, escribe el plan, dirige el motor elegido, revisa el resultado y entrega el paquete.

La regla más importante: no renderices antes de que el plan y la vista previa estén aprobados, a menos que el usuario solicite explícitamente no detenerse. Renderizar es la parte más barata del flujo y el error más costoso de deshacer.

Ejecución del CLI

Esta habilidad incluye su CLI en scripts/rooster.mjs relativo al directorio base de la habilidad. Ejecútalo desde el directorio del proyecto del usuario, resolviendo el script contra la base de la habilidad. En los ejemplos siguientes, <skill> significa ese directorio base:

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

No crees un directorio scripts/ en el proyecto del usuario solo para que el comando funcione. El espacio de trabajo (rooster/) pertenece al proyecto; el CLI pertenece a la habilidad. Si el directorio de trabajo del shell es el directorio de la habilidad, el CLI creará el espacio de trabajo en el lugar equivocado.

Dónde instalar la habilidad

Cuando el usuario te pida instalar RoosterEdit, pregunta primero si la instalación debe ser local al proyecto (recomendada) o global. Usa la carpeta de habilidades que el harness actual realmente lee; no asumas que es OpenCode.

• Local: la carpeta de habilidades a nivel de proyecto del harness más rooster-edit (por ejemplo .opencode/skills, .claude/skills o .agents/skills). Recomendada porque la versión se queda con el proyecto y no puede sorprender a otros trabajos.
• Global: la carpeta de habilidades global del harness más rooster-edit (por ejemplo ~/.config/opencode/skills o ~/.claude/skills). Úsala solo cuando el usuario quiera RoosterEdit en todos los proyectos de la máquina.

Si no puedes determinar las carpetas del harness, inspecciona sus rutas de descubrimiento de habilidades o pregunta al usuario. Espera la respuesta antes de clonar. Esta decisión es sobre dónde vive la habilidad, no dónde vive el espacio de trabajo de video (./rooster).

Informes

Las respuestas al final de una tarea son cortas por defecto: de 5 a 10 líneas o una tabla compacta. Incluye solo lo que el usuario necesita para actuar:

• qué se hizo o encontró;
• las rutas o enlaces al resultado;
• lo que falta o está bloqueado, si algo;
• una pregunta clara para el siguiente paso.

No repitas el resumen, pegues registros, enumeres cada comando o expliques toda la habilidad a menos que el usuario lo pida. Pon los detalles en archivos del espacio de trabajo o enlaza los documentos de referencia. Un plan, un informe de QA o un paquete de entrega pueden ser más largos solo porque el usuario debe revisar su contenido.

La instalación y la configuración del espacio de trabajo son pasos separados. Después de instalar y ejecutar doctor, no comiences la incorporación ni escribas una guía. Resume el entorno en unas pocas líneas y pregunta si el usuario quiere configurar el espacio de trabajo ahora. Espera un "sí" antes de crear rooster/ o un canal.

Actualizaciones de progreso

Usa un marcador de paso compacto en las actualizaciones de estado y en cada punto de aprobación. Mantén un rastreador de 8 pasos para el proyecto:

1. Entorno y espacio de trabajo
2. Resumen y toma de requerimientos
3. Activos y transcripción
4. Plan de edición
5. Storyboard y línea de tiempo
6. Construcción del motor
7. Vista previa y QA
8. Renderizado y entrega

Ejemplos:

• Paso 3/8 — Transcripción completada. 42 fragmentos, duración 10:12.
• Paso 4/8 — Plan listo en edit/plan.html. ¿Puedo continuar con la línea de tiempo?
• Paso 6/8 — Construcción completada. ¿Puedo abrir la vista previa y ejecutar QA?
• Paso 8/8 — Vista previa aprobada. ¿Puedo renderizar el final?

Omite los pasos que no apliquen y explica por qué. No imprimas la lista completa en cada mensaje; muestra el paso actual, qué cambió y el siguiente punto de control. No combines la línea de tiempo y el renderizado final en una sola aprobación: la vista previa y el QA están entre ellos.

Ejecución prioritaria de subagentes

El agente principal es el director, no el trabajador. Habla con el usuario, es dueño del resumen y las decisiones, ejecuta los puntos de aprobación y revisa los fotogramas finales. El trabajo pesado va a un subagente de etapa: análisis de transcripción, investigación, borradores de guion, borradores de plan, estilo y storyboard, construcción y correcciones, barridos de QA, renderizado y empaquetado. Cada subagente tiene su propio contexto, que se descarta cuando termina la etapa, por lo que el material bruto nunca se acumula en el hilo principal.

Delega por defecto siempre que el harness tenga una herramienta de subagente. Mantén la etapa en línea cuando sea un comando barato, cuando sea la conversación en sí (toma de requerimientos, aprobaciones) o cuando sea el juicio visual final.

Etapa	Subagente	Lo que recibe el agente principal
Resumen	productor	resumen de un párrafo + preguntas abiertas
Investigación	investigador	5 hallazgos + fuentes + indicadores de licencia
Transcripción	analista-de-transcripcion	duración, temas, 10–20 puntos, indicadores
Guion	guionista	gancho + resumen de puntos
Plan	editor	resumen del plan + riesgos
Estilo/storyboard	director-de-arte	tokens + conteo de escenas + necesidades de activos
Línea de tiempo	editor	matemática de duración + marcadores
Audio	director-de-audio	decisiones de voz/música/mezcla
Construcción	ingeniero	estado + rutas de artefactos + bloqueos
QA	qa	veredicto + problemas principales + rutas de fotogramas
Renderizado	ingeniero	ruta final + estadísticas de sonda

Genera con un prompt corto: ruta del archivo de rol, ruta del proyecto, una frase de tarea, rutas de entrada, restricciones. Pasa rutas, nunca el resumen, la transcripción, los registros o el contenido del plan. Si la entrada es la conversación en sí, escribe las respuestas en work/intake.md primero. Pide la transferencia descrita en references/subagents.md y nada más. Usa el agente de propósito general o trabajador del harness para etapas que escriban archivos o ejecuten comandos; un tipo de solo lectura o investigación está bien para la investigación. Esto es una capacidad, no un nombre de herramienta: si el harness no puede iniciar un agente nuevo con acceso a archivos y comandos, o si una generación falla dos veces, ejecuta la etapa en línea y mantén los límites de archivos.

La transferencia es lo único que entra en el contexto principal:

estado: ok | necesita-decision | bloqueado
artefactos: rutas que existen
resumen: <= 5 líneas
decisiones: lo que el agente principal debe confirmar
bloqueos: lo que detiene la etapa
siguiente: siguiente etapa o pregunta exacta

El agente principal puede leer el resumen, el guion, el estilo, review.md y las transferencias, y puede ver plan.html y de 3 a 5 fotogramas. No debe leer la transcripción bruta, el JSON completo del plan, el código generado, los registros de construcción/renderizado o una hoja de contacto con decenas de fotogramas. Si falta un detalle, envía un seguimiento al mismo subagente en lugar de abrir el archivo bruto.

Nada de esto es una dependencia. Los artefactos y los puntos de control son los mismos cuando una etapa se ejecuta en línea; pierdes el aislamiento del contexto, no el flujo de trabajo.

Los puntos de aprobación nunca se mueven a un subagente. El subagente propone; el usuario y el agente principal deciden.

Primera ejecución después de la instalación

Si el espacio de trabajo aún no existe, haz una breve incorporación antes de crear cualquier proyecto.

Primero pregunta: "¿Quieres configurar el espacio de trabajo ahora?" Explica en una línea que esto crea rooster/ y el primer canal. Si la respuesta es no, detente y no crees nada.

Si la respuesta es sí:

1. Usa ./rooster por defecto. No preguntes "¿dónde vive el espacio de trabajo?" a menos que el usuario quiera una ruta personalizada.
2. Haz una pregunta: "¿Qué va a producir este canal? Una frase basta." Usa la respuesta y la conversación para deducir el nombre del canal, idioma, formato, fuente, perfil, activos, motor, autonomía y voz. No preguntes los doce campos del canal y no pidas una duración.
3. Muestra los valores predeterminados deducidos en una línea compacta y pregunta "¿Está bien o quieres ajustar algo?" Haz una pregunta de seguimiento solo cuando un campo sea genuinamente ambiguo, como la plataforma o si la fuente es material real.
4. Tras la confirmación, ejecuta init, luego channel new <id> ... con las respuestas. Muestra un resumen corto y detente.

La duración no es un valor predeterminado del canal: pertenece a cada proyecto y se elige cuando se crea el video. La configuración completa de doce campos es una ruta avanzada opcional. Si el usuario pide personalizar todo, pregunta en grupos de máximo tres, nunca todos a la vez.

Un canal es el grupo estable para una marca, audiencia u operación (por ejemplo "EN Tech" o "PT Creador"). Es dueño de los valores predeterminados creativos: idioma, formato, perfil, política de activos, motor, autonomía y voz. Cada proyecto pertenece a un canal y puede anular cualquiera de esos valores predeterminados. La duración es por proyecto, no un valor predeterminado del canal.

No empieces un video en el mismo turno a menos que el usuario lo solicite explícitamente. Lee references/onboarding.md para las preguntas exactas, valores predeterminados y comandos. Lee references/assets.md antes de descargar o generar cualquier activo.

Ruta rápida: el flujo de trabajo de video en 6 pasos

Cuando el usuario quiera la ruta más simple desde el material bruto hasta un video terminado, sigue los mismos seis pasos que el flujo de trabajo de referencia, adaptados al espacio de trabajo de RoosterEdit:

1. Prepara la máquina — FFmpeg, Node.js LTS, Python 3, HyperFrames y Whisper (o Parakeet/whisper.cpp de HyperFrames). Pregunta antes de instalar algo.
2. Crea o resuelve el proyecto — rooster new ...; el material bruto va en assets/source/.
3. Escribe la guía de estilo — director-de-arte escribe style.md y resuelve el perfil. Ejecuta styleproof <slug> y aprueba las tres muestras de fotogramas antes de planificar.
4. Transcribe y planifica — analista-de-transcripcion escribe edit/transcript.json, edit/digest.md y edit/analysis.json; editor escribe edit/plan.json a partir del análisis y style.md. Muestra plan.html con contexto de transcripción y espera la aprobación.
5. Crea los elementos visuales — ingeniero construye letreros, gráficos, listas, zooms, material de archivo, tercios inferiores, música y efectos de sonido cuando el estilo del canal lo requiera. Un borrador solo con cortes no es un video terminado a menos que el usuario haya solicitado explícitamente un corte limpio.
6. Ensambla, revisa, exporta — ingeniero ejecuta build para generar el proyecto de HyperFrames o Remotion a partir del plan aprobado; usa --sample 3 antes de la construcción completa. qa inspecciona preview/index.html y los fotogramas, luego ingeniero renderiza en renders/; export escribe un archivo de transferencia EDL/FCPXML cuando el usuario quiera DaVinci o Premiere.

Lee references/video-pipeline.md para los comandos exactos y la correspondencia de las carpetas del video de referencia a las nuestras. El resto de esta habilidad es el modo de estudio más amplio; la ruta rápida es el valor predeterminado para trabajos de un solo video.

Principios operativos

• Dirige antes de generar. Un resumen claro, un guion y una lista de tomas ahorran más tiempo que cualquier ajuste de prompt. Dedica la primera parte del trabajo a entender el video.
• Inspecciona, no asumas. Lee los archivos, examina el material, mira los fotogramas y verifica las herramientas. Nunca afirmes que un renderizado o un activo existe porque el código se ve bien.
• Mantén la edición editable. Prefiere escenas con nombre, variables y componentes legibles sobre scripts únicos. El usuario debería poder cambiar un color, una línea o un clip sin reescribir el proyecto.
• Revisa con ojos. Usa la vista previa del navegador, capturas de pantalla o fotogramas renderizados para juzgar la composición, el ritmo y los subtítulos. La revisión de código por sí sola no es suficiente.
• Respeta la procedencia. Registra de dónde vino cada activo y su licencia. Un video hermoso con una pista sin licencia es un riesgo.
• Degrada con gracia. El harness puede no tener subagentes, navegador, Node, FFmpeg o TTS. Ofrece la mejor ruta disponible y di qué falta.
• Delega las etapas pesadas. El agente principal dirige; los subagentes de etapa hacen el trabajo pesado y devuelven una transferencia corta. Las transcripciones, los registros de construcción, el código generado y los barridos de QA no deben pasar por el contexto principal. Lee references/subagents.md.
• Informa breve. Termina cada tarea con el resultado, las rutas y una próxima pregunta. No narres todo el proceso ni vuelques comandos a menos que el usuario lo pida.
• Termina la capa creativa. Los cortes solos no son un video. Planifica superposiciones, material de archivo, música, efectos de sonido o subtítulos a menos que el usuario haya solicitado explícitamente un corte limpio.
• Pregunta cuando haya incertidumbre. Si una elección cambia el corte, el aspecto, el audio o el costo, pregunta en el Paso X/8 actual. No adivines en silencio.
• Protege el contexto. El trabajo de video consume muchos tokens. Redirige los registros del motor a archivos, lee solo la cola, usa digest en lugar de la transcripción completa e inspecciona unos pocos fotogramas clave en lugar de cada fotograma. Lee references/token-discipline.md.

Paso 0 - Encuentra el espacio de trabajo

Busca un directorio rooster/ en el proyecto actual primero, luego usa ROOSTER_WORKSPACE si está configurado. El valor predeterminado es ./rooster; solo pregunta por una ruta personalizada cuando el usuario quiera una.

Si ninguno existe y el usuario ya ha pedido hacer un video, crear el espacio de trabajo está implícito; ejecuta:

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

Si el usuario acaba de instalar la habilidad o solo está explorando, no lo crees en silencio: sigue "Primera ejecución después de la instalación" y pregunta primero.

El espacio de trabajo es donde viven los canales, proyectos, perfiles y la biblioteca de activos. Mantenlo fuera del directorio de la habilidad; la habilidad es reutilizable, el espacio de trabajo pertenece al proyecto de video del usuario.

Si el espacio de trabajo existe pero no tiene canal, crea uno antes de crear un proyecto. Cada proyecto pertenece a un canal; un canal default cubre videos únicos.

Si el usuario solo está haciendo una pregunta o explorando una idea, responde sin crear un espacio de trabajo. Una pregunta no es una solicitud para construir.

Paso 1 — Verifica capacidades

Ejecuta:

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

Esto informa Node, npm, Python, FFmpeg, FFprobe, Git, GPU, motores detectados, proveedores de TTS, yt-dlp, Whisper y el CLI de HyperFrames. El harness mismo sabe si los subagentes y un navegador están disponibles; combina ese conocimiento con la salida del CLI. Para costos, lee docs/COSTS.md; nunca llames a un proveedor de pago sin permiso explícito.

Lee references/harness.md cuando algo falte. La versión corta:

• Sin Node: usa FFmpeg directamente para cortes y audio, pero no puedes ejecutar HyperFrames o Remotion.
• Sin FFmpeg: aún puedes planificar, escribir guiones y hacer storyboards, pero no puedes sondear ni renderizar localmente.
• Sin navegador: renderiza fotogramas fijos o imágenes e inspecciónalos como imágenes.
• Sin TTS: usa la voz del usuario, solo subtítulos o un motor local.

...