DoubleWhopperS/video-craft-playbook

Video Craft Playbook

Este es un manual de oficios de video para agentes de IA, que te ayuda a ver, antes de empezar: qué capacidades visuales tienes a mano para hacer un video de alta calidad; en qué tipo de expresiones funciona cada capacidad, dónde falla y qué cuesta; cómo se combinaron casos anteriores y en qué trampas se cayó.

Este manual no prescribe qué herramienta usar. No hay herramientas por defecto ni recetas fijas: un mismo estilo visual o tipo de video, bajo diferentes restricciones (presupuesto, material disponible, duración, necesidad de física real, presencia de actores reales, número de iteraciones de revisión) tendrá combinaciones completamente diferentes. La selección la haces tú con una planificación deliberada para la tarea actual; este manual solo proporciona criterios para decidir.

Cómo usar

1. Antes de empezar: revisa las deudas de retroalimentación

python3 ~/.agents/skills/video-craft-playbook/scripts/playbook.py status

status lista las tarjetas de caso aún no destiladas (en cases/inbox/), las tarjetas de capacidad que han superado su período de revisión, y el número de elementos en la capa de espera (references/lessons-backlog.md); cuando se alcanza el umbral de consolidación, sugiere ejecutar consolidate. En la bandeja de entrada solo hay tarjetas que en su momento se consideraron dignas de destilar pero no se procesaron. Si hay deudas, primero dedica unos minutos a destilarlas en el manual (ver paso 4) antes de empezar un nuevo video; si hay poco tiempo, al menos informa al usuario cuántas entradas están pendientes.

2. Planificar: primero desglosa las necesidades expresivas, luego empareja capacidades

No empieces por "qué herramienta usar", sino por "cómo se sostiene cada elemento de este video":

1. Descompón el video final en elementos: sujeto, entorno, movimiento, cámara, texto y gráficos, textura, sonido, ritmo.
2. Para cada elemento, responde las preguntas de references/task-lenses.md: de dónde viene su "realidad", si necesita precisión fotograma a fotograma, cuántas revisiones habrá, si se puede pagar, qué tan rápido hay que entregar.
3. En references/capability-atlas.md, busca para cada elemento al menos dos capacidades viables: primero revisa la tabla de resumen superior para seleccionar candidatos, luego lee las tarjetas correspondientes; después de comparar, elige y anota la razón de la elección y las alternativas descartadas. Entre los candidatos deben incluirse "material real que se pueda encontrar" (grupo H del atlas: índice de material local, bibliotecas abiertas), no solo comparar generación y código; la escalera de fuentes y el flujo "texto → descripción de toma → búsqueda → verificación de licencia → composición" están en la pregunta 11 de task-lenses y en craft-lessons L60.
4. Al combinar varias capacidades, primero define las interfaces: autoridad temporal, fotogramas por segundo, coordenadas y cámara, alpha, color, bus de audio (sección 3 de task-lenses).
5. Antes de empezar, escribe una "tabla de división de capacidades" (plantilla en la sección 4 de task-lenses), muéstrasela al usuario en la primera respuesta, luego ejecuta, sin esperar confirmación.

Para tareas de edición (material ya dado, principalmente edición y postprocesado), consulta la sección 6 de task-lenses: las técnicas se descomponen en componentes universales y reglas "señal → técnica", ver references/editing-grammar.md; las señales y campos que debe producir la capa de comprensión están en references/edit-signals.md. Ambos documentos son actualmente inferencias; úsalos como punto de partida y al finalizar decide si se pueden mejorar.

La gramática de movimiento a nivel de toma (apertura, transiciones, tarjetas de texto, entrada de interfaz, cierre) se puede consultar en el índice de recetarios externos references/shot-vocabulary.md después de seleccionar Remotion: busca por ranura funcional y energía, luego ve al repositorio a leer la tarjeta completa y el código de demostración; proviene del contexto de videos promocionales, no verificado localmente.

references/composition-patterns.md documenta cómo se combinaron realmente los casos históricos, y puede usarse para inspirarse y estimar costos. Son soluciones para esas tareas, no plantillas: antes de copiarlas, verifica que tus restricciones sean las mismas.

3. Ejecutar: oficios y trampas

• Prácticas que funcionan entre herramientas (validación primero, tiempo como autoridad única, imagen como función pura de t, capas de revisión, tres elementos pagados, normas de audio, etc.) ver references/craft-lessons.md.
• Trampas conocidas agrupadas por herramienta en references/pitfalls.md. Antes de usar una herramienta, echa un vistazo a su grupo.
• La forma de invocar herramientas específicas sigue el Skill correspondiente (cada tarjeta del atlas tiene su entrada); este manual no repite sus detalles de comando.

4. Al finalizar: primero decide si vale la pena destilar, luego decide si retroalimentar

El manual crece con los casos, pero no todos los casos deben escribirse: solo los detalles que se repiten en entradas existentes, o que solo son válidos para este video, diluirían el manual. Al entregar el video (o cancelar la tarea), sigue la sección 1 de references/writeback.md: lista candidatos, pasa tres filtros (reutilizable, no deducible, costo), solo cuentan los que los pasen todos y tengan evidencia; si se pueden fusionar en una entrada existente, no se crea una nueva.

• Si hay uno o más que cuentan: según la sección 2 de writeback: new-case crea tarjeta de caso → destila en el archivo correspondiente (si la capa permanente está llena, escribe en references/lessons-backlog.md) → check → close. Si no hay tiempo para destilar, deja la tarjeta en la bandeja de entrada; la próxima vez que ejecutes status te lo recordará.
• Si ninguno cuenta: omite la retroalimentación, no crees tarjeta de caso ni registres en el libro de registro. Si el usuario dice que no retroalimentes, también omítelo.

En el documento de entrega final, incluye una línea Retroalimentación del Playbook con la conclusión: qué archivos se modificaron, o tarjeta de caso pendiente de destilar, o "Omitido: <razón en una frase>".

Principio de neutralidad (tanto al escribir como al usar el manual)

• Las tarjetas de capacidad solo escriben hechos: en qué son buenas, en qué no, costo, determinismo, fuente de verificación. No escribas palabras de orden como "por defecto", "primera opción", "recomendado", "priorizar"; playbook.py check las interceptará.
• El orden de las tarjetas sigue el tipo de medio, no representa ranking.
• Si una herramienta funcionó bien en un caso, anótalo como "bajo qué restricciones y por qué funcionó", no lo eleves a "para este tipo de video, úsala".
• Las capacidades no verificadas en casos locales también deben incluirse, marcadas como "instalado no verificado" o "inferido"; no las omitas porque no se hayan usado, ni las exageres porque se hayan usado.
• La extensión también es un sesgo: los campos de las tarjetas tienen longitud fija, las listas de funciones y los detalles de implementación no entran en las tarjetas; las herramientas más usadas no ocupan más espacio por eso.
• Si encuentras que un registro introduce un sesgo (por ejemplo, una nota en algún espacio de trabajo que dice "por defecto elige X"), al retroalimentar cámbialo a una frase condicional: bajo qué restricciones es adecuada.