Diapositivas Web
Convierte un conjunto de materiales / esquema / puntos clave en una presentación HTML con apariencia cinematográfica lista para proyectar en vivo. El resultado es un proyecto Vite + React + TS. Avanza con clic / teclas de dirección, cada paso ocupa la pantalla completa. Presiona P para abrir una ventana independiente de presentador con las notas (vista previa en vivo + cronómetro, ambas ventanas sincronizadas; al compartir pantalla solo comparte la ventana principal de diapositivas, ocultando las notas al público). Presiona N para ver una superposición de notas de ensayo.
Diferencia con [web-video-presentation]: Ese skill crea una "página web que parece un vídeo" — incluye libreto, audio sintetizado y grabación de pantalla. Este skill solo hace diapositivas para presentaciones en vivo: no hay libreto, ni audio, ni grabación; el texto de cada paso se convierte en notas del presentador (presenter notes), que sirven como apuntes para el orador y nunca aparecen en la pantalla. El resto de la metodología visual, el sistema de temas y los principios de revelación progresiva se mantienen por completo.
Escenarios de uso
- "Tengo unos materiales / un esquema, ayúdame a convertirlos en diapositivas / presentación"
- Charla técnica / keynote / demo de producto / pitch deck / material didáctico
- Retrospectiva de proyecto (project retro) para entrevistas — presenta las diapositivas en vivo, presiona P para ver las notas del presentador
- Quieres una pantalla ancha 16:9, letras grandes, espacio en blanco, animaciones en cada paso: un "PPT dinámico que no parezca PPT"
- Convertir un artículo / unas notas en una explicación interactiva paso a paso
Este skill se centra en metodología y flujo de trabajo colaborativo. La plantilla proporciona tokens y primitivas, pero cada decisión estética (paleta de colores, tipografía, estilo de animación) debe rediseñarse para tu tema específico — no copies y pegues.
Dos perfiles de densidad: modo vídeo / modo deck de presentación
El mismo motor puede ejecutar dos ritmos diferentes. Elige uno en la Fase 1 (escríbelo al inicio de outline.md, y el Checkpoint Plan lo confirma con el usuario):
| 🎬 Modo vídeo (por defecto / disperso) | 🎤 Modo deck de presentación (páginas limitadas / alta densidad) | |
|---|---|---|
| Escenario | Explicación grabada, se habla sin parar, muchos compases | Presentación en vivo / proyección, páginas limitadas, se habla alrededor de una página (común en retros de entrevistas) |
| Una diapositiva | = un paso (ocupa toda la pantalla) | = un capítulo (una página densa y estable) |
| Significado de paso | Cambiar a la siguiente idea (cambio de escena) | Construir progresivamente en la misma diapositiva (los elementos permanecen en pantalla y aparecen gradualmente, sin cambiar de escena) |
| Información por pantalla | 1 hero + 1~3 elementos + mucho espacio en blanco | Imagen / tabla / diagrama + varios puntos clave + datos pueden coexistir |
| Escala | Muchos capítulos × pocos pasos | Pocos capítulos (≈ número de páginas objetivo) × 2~5 construcciones por capítulo |
| Tema | Cualquiera | Priorizar temas estructurales / editoriales (newsroom / monochrome-print / blueprint / swiss-ikb / vintage-editorial) |
Ninguno de los dos cambia el motor (capítulo/paso, lienzo 16:9, tokens, MaskReveal son todos comunes). La diferencia está en cómo se escribe el capítulo. El modo deck relaja la regla de "una idea por pantalla / mucho espacio en blanco / hero completo", pero "evitar el olor a IA" + tokens + jerarquía real + debe tener demostración visual + doble fuente se mantienen — esa es la base para que "no se vea mal". La escritura detallada de cada capítulo está en CHAPTER-CRAFT.md en la sección "Dos perfiles de densidad".
Si no estás seguro → 🎬 modo vídeo.
Resumen del flujo de trabajo
Fase 1 Planificación del contenido
1.1 Identificar la entrada del usuario
1.2 Generar outline.md
(división en capítulos + contenido de cada paso + notas opcionales por paso + pool de información)
▼
[Checkpoint Plan] ← Debes detenerte. Alinear 4 cosas de una vez:
esquema / tema / materiales / modo de desarrollo
▼
Fase 2 Desarrollo web
2.1 Scaffolding (según el tema seleccionado)
2.2 Capítulo 1 = hilo principal + versión completa (ancla obligatoria)
▼
[Punto duro] El usuario aprueba el Capítulo 1 ← No se puede saltar
▼
2.3 Capítulos 2~N (según el modo seleccionado: A capítulo por capítulo / B secuencial / C paralelo)
▼
[Checkpoint Done] ← Diapositivas terminadas, servidor de desarrollo funcionando
▼
Fase 3 Presentación / Exportación
No hay fases de "síntesis de audio" ni "grabación de pantalla" — esto son diapositivas, no un vídeo.
Convención del directorio de trabajo (el agente crea/edita en el directorio actual del usuario):
my-slides/
├── material.md # Se conserva si el usuario proporcionó material original — ¡no lo borres! Fuente de información visual durante el desarrollo
├── outline.md # Obligatorio: plan de desarrollo (división en capítulos + contenido de cada paso + pool de información + notas opcionales)
└── presentation/ # Proyecto Vite + React + TS generado por el scaffolding
└── src/chapters/<NN>-<id>/
├── <Chapter>.tsx # Implementación visual
├── <Chapter>.css
└── notes.ts # ★ Única fuente de verdad: número de pasos + notas del presentador
Clave:
notes.tses la única fuente de verdad para el número de pasos. El máximo N + 1 que aparece enif (step === N)en el.tsxdel capítulo debe ser igual anotes.length. Esto garantiza que el código del capítulo, la barra de progreso y el stepper nunca se desincronicen. El contenido de las notas (los strings del array) solo se alimenta a la ventana del presentador (tecla P) y a la superposición de notas (tecla N), nunca aparecen en la pantalla de diapositivas. Se pueden dejar vacíos con"".
Protocolo de auto-revisión estricto (aplica en todo el Skill)
Para los dos productos siguientes, cada uno debe pasar por auto-revisión → reparación → luego informar/avanzar:
| Producto | Origen de la lista de verificación |
|---|---|
outline.md | Lista de verificación en OUTLINE-FORMAT.md |
| Implementación de un capítulo completada | Lista de verificación de finalización en CHAPTER-CRAFT.md |
Método de ejecución (en orden descendente de capacidad, prioriza el método más aislado):
- Agent Teams (óptimo): Abre un agente revisor independiente, pásale "ruta del archivo generado + lista de verificación correspondiente + contexto clave", haz que verifique elemento por elemento y reporte estrictamente las conclusiones (qué elementos pasan / cuáles fallan + evidencia + sugerencias de modificación).
- subAgent (segunda opción): Si no tienes capacidad de Teams pero puedes abrir un subagente, úsalo para el mismo proceso.
- Auto-revisión (último recurso): Si el agente actual no tiene ninguna de las capacidades anteriores, haz la verificación estrictamente elemento por elemento tú mismo — no está permitido echar un vistazo y dar el visto bueno.
Regla de hierro: Después de obtener las conclusiones, primero corrige los elementos que fallaron en el producto, y luego informa al usuario: "terminado + conclusión de la revisión + qué se modificó". Informar directamente con las conclusiones originales sin reparar = infracción.
Guía de lectura de archivos por fase
Diferentes fases leen diferentes archivos. En sesiones largas el agente tiende a olvidar los principios, especialmente en la Fase 2.4 "implementar un capítulo" que se repite N veces — cada vez hay que volver a consultar las restricciones centrales.
| Fase | Lectura obligatoria (cada vez) | Leer una sola vez / consultar según necesidad |
|---|---|---|
| Fase 1.1-1.2 Planificación de contenido | references/OUTLINE-FORMAT.md + material.md (material original del usuario, si existe) | —— |
| Checkpoint Plan Elegir tema | —— | themes/*/theme.json (leer todos dinámicamente, listar + recomendar bestFor + descriptionZh); references/THEMES.md (cuando el usuario quiera conocer el sistema de temas) |
| Fase 2.1 Scaffolding | —— | Leer esta sección de SKILL.md una vez |
| Fase 2.4 Implementar un capítulo (×N veces, llamado por 2.2 / 2.3) | references/CHAPTER-CRAFT.md como única entrada — requisitos de demostración visual / revelación progresiva / selección de contenido / doble fuente (outline+material) / estética de presentación / evitar olor a IA / restricciones mínimas de código (incluye restricción obligatoria de notes.ts) / referencia de duración / auto-revisión de finalización + themes/<id>/theme.json del tema actual + el párrafo correspondiente del capítulo actual en outline.md + el párrafo correspondiente de material.md + lista de materiales | references/EXAMPLES/ (referencia estructural, no plantilla para copiar); references/THEMES.md (contrato completo de tokens) |
| Fase 3 Presentación / Exportación | references/PRESENTING.md (pantalla completa, navegación por teclado, presionar N para notas, exportar PDF / capturas de pantalla) | —— |
| Seleccionar / Crear / Modificar tema | —— | references/THEMES.md |
Al escribir un capítulo, lee solo
CHAPTER-CRAFT.md. Los diez principios / auto-prompting inicial / árbol de decisiones / antipatrones anti-IA / auto-revisión de finalización están todos integrados en esta única entrada.EXAMPLES/no es lectura obligatoria — primero diseña libremente según el contenido, solo consulta si te estancas (consulta la "forma" del ancla, no copies).
Fase 1 — Planificación del contenido
1.1 Identificar la entrada del usuario
| Lo que el usuario da | Qué hacer |
|---|---|
| Material original (artículo / notas / lista de puntos / datos) | Generar outline.md (1.2), conservar el material original como material.md, pasar por Checkpoint Plan |
| Un esquema / guion ya escrito | Formatearlo como outline.md (1.2), pasar por Checkpoint Plan |
| Sin nada, solo dice "hazme unas diapositivas sobre el tema X" | Pregunta de vuelta: primero proporciona un fragmento de material o puntos clave. El skill no concibe el contenido por el usuario |
1.2 Generar outline.md
Sigue las reglas de references/OUTLINE-FORMAT.md: dividir en capítulos → dividir en pasos → extraer pool de información en el primer párrafo de cada capítulo → escribir el contenido de la pantalla para cada paso (+ sugerencia opcional de notas del presentador).
Primero define el perfil de densidad (🎬 modo vídeo / 🎤 modo deck, ver arriba "Dos perfiles de densidad") — determina directamente cómo se dividen los capítulos: en modo deck, el número de capítulos ≈ el número de páginas objetivo, cada capítulo tiene 2~5 construcciones.
Conserva material.md sin borrar — es la fuente de detalles para escribir el pool de información en outline y la implementación visual de los capítulos (principio de doble fuente).
Límites del outline (clave):
| outline debe escribir | outline no debe escribir |
|---|---|
| División en capítulos / número de pasos por capítulo / tiempo estimado | Tipo de animación específica (blur clear / wipe / spring) |
| Contenido de la pantalla por paso (hero / datos / eslogan / elementos de lista) | Medios de implementación CSS (filter / SVG / clip-path) |
| Pool de información a nivel de capítulo: números / citas / casos / etiquetas extraídos del material | Valores numéricos de duración / micro-ritmo |
| Sugerencia de notas del presentador por paso (opcional: qué piensas decir en este paso) | Micro-ritmos como micro-movimientos continuos / desfase |
| Prefijo de relación entre pasos (opcional: "contraste", "lista progresiva", "frase destacada", etc.) | —— |
Razón para no escribir animaciones en el outline: Escribir animaciones fijas degrada al agente del capítulo a un traductor; dejar espacio en blanco permite que el agente del capítulo diseñe libremente siguiendo el "árbol de decisiones impulsado por el contenido" de
CHAPTER-CRAFT.mdal iniciar cada paso, logrando una verdadera sensación visual.
Después de guardar, primero debes pasar por auto-revisión antes de entrar en Checkpoint Plan: Sigue el "Protocolo de auto-revisión estricto" anterior para outline.md (prioriza Agent Teams → subAgent → auto-revisión), repara según las conclusiones y luego continúa.
Checkpoint Plan — Alinear 4 cosas de una vez (Punto duro)
Después de escribir outline.md debes detenerte. El usuario confirma 4 cosas simultáneamente en este punto.
Trabajo preparatorio del agente en este momento
- Leer todos los
themes/*/theme.jsonpara obtenernameZh/descriptionZh/bestFor/mood— no codifiques la lista - Según el tipo de contenido / palabras clave / tono del outline, seleccionar activamente 2~3 temas más adecuados (coincidiendo con el campo
bestFor) - Revisar la sección "Lista de materiales" al final de
outline.md
Plantilla de resumen (esqueleto, el agente lo rellena según el caso)
El plan de contenido está escrito, archivos generados:
📄 material.md {si el usuario dio material original, se conserva}
📄 outline.md {N} capítulos / {M} pasos + pool de información por capítulo + lista de materiales al final
Resumen de capítulos:
1. <id> <Título del capítulo> <S> pasos ~<T>s
2. ...
A continuación, alinear 4 cosas de una vez:
1. ¿Hay que modificar el plan de desarrollo (outline.md)? Céntrate en:
- ¿El perfil de densidad es correcto? (🎬 modo vídeo: muchos pasos dispersos / 🎤 modo deck: páginas limitadas, alta densidad)
- ¿La división en capítulos / el número de pasos es razonable? (~5~12 pasos por capítulo es un rango común)
- ¿El contenido de la pantalla por paso es claro?
- ¿El "pool de información" al inicio de cada capítulo tiene suficientes detalles del material para anclar la imagen?
- ¿La lista de materiales al final está completa?
2. ¿Qué tema elegir? Mis recomendaciones:
★ <Recomendación 1: nameZh (id)> — porque <coincidencia con bestFor>; <resumen de descriptionZh>
★ <Recomendación 2 / Recomendación 3>
Otras opciones: <temas restantes, nameZh + una frase>
También puedo ayudarte a crear un tema nuevo (ver references/THEMES.md para más detalles).
3. ¿Cómo preparar los materiales reales? Un vistazo rápido a las imágenes que necesita esta presentación: <lista aproximada>
a) Yo selecciono de <ruta de material existente> b) Tú los proporcionas c) Todos placeholder
4. ¿Qué modo de desarrollo elegir?
**El Capítulo 1, independientemente del modo, debe hacerse en el hilo principal y ser aprobado por el usuario** (ancla obligatoria).
La diferencia está a partir del Capítulo 2:
A) Por defecto · Capítulo por capítulo con confirmación (recomendado)
Cada capítulo terminado se detiene para aprobación → riesgo controlable / ritmo más estable
B) Desarrollo secuencial después del Capítulo 1 (sin paralelo)
Capítulos 2~N se hacen secuencialmente en el hilo principal y se aprueban al final → velocidad media / adecuado si el agente no soporta paralelo
C) Desarrollo paralelo después del Capítulo 1 (subagentes)
Capítulos 2~N en paralelo con subagentes → más rápido / el usuario controla el número de paralelismo (cuántos capítulos a la vez)
⚠️ Los estilos pueden variar entre capítulos (esto es esperado, los tokens del tema ponen un límite)
Después de recibir comentarios:
- Si hay que modificar outline: editar el archivo directamente, después de editar ping una vez (o describir oralmente lo que el agente modificó)
- El tema debe estar claro para entrar en Fase 2. Si el usuario dice "tú eliges el tema" → toma tu primera recomendación, dile al usuario qué elegiste y por qué, dale la oportunidad de cambiar de opinión
- Modo seleccionado → entrar en Fase 2
Fase 2 — Desarrollo web
2.1 Scaffolding
bash <path-to-web-slides>/scripts/scaffold.sh \
./presentation \
--theme=<id del tema seleccionado por el usuario>
bash <path-to-web-slides>/scripts/scaffold.sh --list-themes
Tema personalizado → primero sigue el flujo de "Crear un nuevo tema" en
references/THEMES.mdpara hacer unthemes/<my-theme>/, luego--theme=<my-theme>.
El scaffolding incluye una demo 01-example. Bórrala antes de escribir el contenido real del primer capítulo:
rm -rf presentation/src/chapters/01-example
Y elimina el import y el elemento del array del capítulo example en presentation/src/registry/chapters.ts.
2.2 Capítulo 1 — Hilo principal + Aprobación obligatoria
Clave: El Capítulo 1 = versión completa de una sola vez (ritmo + visual + materiales reales completos). No existe el concepto de "versión esqueleto" — el primer capítulo debe ser una muestra que el usuario pueda aprobar directamente.
Por qué el Capítulo 1 debe ser en el hilo principal:
- Es la primera aplicación de las pautas de
CHAPTER-CRAFT.mden el tema actual + material actual - Si hay puntos ciegos en las pautas / colores del tema / tokens de fuente insuficientes, el Capítulo 1 los expondrá — ahí se puede obtener feedback humano para ajustar las pautas o el tema, cuanto antes se corrija, menor el costo
- Los capítulos posteriores (sean secuenciales o paralelos) deben tomar como referencia el patrón de código del Capítulo 1, por lo que el Capítulo 1 = ancla estilística del proyecto actual
Después de terminar el Capítulo 1, debes detenerte y esperar la aprobación del usuario:
El Capítulo 1 <id> está terminado. El servidor de desarrollo se ejecuta en localhost:5174.
Puntos clave para la aprobación:
□ ¿El aspecto visual es correcto? ¿Coincide con las expectativas de <nameZh del tema>?
□ ¿El ritmo es correcto? ¿Algún paso demasiado rápido / lento / con poca información?
□ ¿Las animaciones están impulsadas por el contenido? ¿O hay pasos con animaciones de entrada sin sentido?
□ Principio de doble fuente: ¿Hay detalles en la pantalla que "las notas no mencionan pero el material sí soporta"?
□ Verificación anti-olor a IA: ¿Hay degradados púrpura-rosa / bordes redondeados de colores / ilustraciones falsas / emojis?
□ Presiona N para ver las notas del presentador, ¿suena natural al leerlas?
Dime si hay problemas, los ajustaré específicamente. Cuando esté bien, dime "continúa" y haré los Capítulos 2 y siguientes según el modo seleccionado.
2.3 Capítulos 2~N — Según el modo seleccionado
Regla común para todos los modos: Cada capítulo se desarrolla de forma independiente siguiendo CHAPTER-CRAFT.md. No se fuerza una consistencia estricta entre capítulos — los tokens de color / fuente del tema garantizan la unidad visual de base; las animaciones / ritmo / demostración visual son libres en cada capítulo, y eso es parte del diseño esperado.
Modo A · Por defecto · Capítulo por capítulo con confirmación
Terminar Capítulo 2 → Pausar para aprobación → OK → Capítulo 3 → Pausar → ... → Capítulo N. Cada capítulo se aprueba de forma independiente, los problemas se corrigen sobre la marcha, riesgo mínimo, ritmo más estable. Si el usuario no especifica un modo, se usa este por defecto.
Modo B · Desarrollo secuencial después del Capítulo 1
Capítulo 2 → Capítulo 3 → ... → Capítulo N se hacen secuencialmente en el hilo principal, y se aprueban todos al final. Velocidad media, adecuado para entornos donde el agente no soporta tareas paralelas.
Modo C · Desarrollo paralelo después del Capítulo 1 (subagentes)
Usar subagentes para hacer los Capítulos 2~N en paralelo. El número máximo de paralelismo lo controla el usuario ("4 capítulos a la vez" / "2 capítulos a la vez"). Más rápido, pero los estilos pueden variar entre capítulos — esto es esperado, porque:
- Cada subagente no ve la salida de otros subagentes, no puede alinearse mecánicamente
- El código de los capítulos está físicamente separado (una carpeta por capítulo / su propio prefijo CSS), no se rompen entre sí
- Los tokens del tema garantizan la unidad visual de base (colores / fuentes / números hero / tarjetas / líneas divisorias / decoración), el estilo no se desvía
- Inconsistencia de estilo = sensación de respiración hecha a mano (múltiples voces / múltiples perspectivas)
El prompt del subagente paralelo debe incluir:
- El párrafo del capítulo actual en el outline (incluyendo el pool de información)
- La ruta de
references/CHAPTER-CRAFT.md(lectura única obligatoria) descriptionZh/mood/bestFordeltheme.jsondel tema actual- El código del Capítulo 1 como referencia de "estilo de código" (no como "objeto de copia visual")
- Reglas estrictas: prefijo CSS independiente por capítulo (
.cd-/.mg-/.pm-/ ...); no modificarchapters.ts; cada capítulo incluyenotes.ts(longitud = número de pasos); al terminar, ejecutarnpx tsc --noEmit
Importante: Independientemente del modo elegido, el usuario puede cambiar de modo en cualquier momento.
2.4 Implementar un capítulo (obligatorio para cada capítulo)
Las pautas detalladas están en references/CHAPTER-CRAFT.md — única entrada de lectura obligatoria, que cubre: requisitos de demostración visual / revelación progresiva / selección de contenido / principio de doble fuente / estética básica de la presentación / anti-olor a IA / líneas rojas de código / auto-revisión de finalización.
Puntos clave (detallados en CHAPTER-CRAFT.md):
- Cada capítulo debe tener una demostración visual con CSS / SVG / Canvas / JS, prohibidos los capítulos de solo texto
- Revelación progresiva: Las listas / enumeraciones deben tener 1 elemento = 1 paso, prohibido mostrar todo a la vez
- Principio de doble fuente: El ritmo sigue el outline (el orden no puede alterarse), los detalles se extraen del material original (pool de información + párrafo de material del capítulo)
- Cada capítulo incluye
notes.ts: longitud = número de pasos (única fuente de verdad), el contenido son notas del presentador (se puede dejar vacío con""), no aparecen en la pantalla - Pasar la auto-revisión de finalización elemento por elemento, si no se cumple, volver a modificar — seguir el "Protocolo de auto-revisión estricto", corregir antes de informar al usuario sobre la entrega del capítulo
2.5 Incrementar STORAGE_KEY después de cambios grandes
Después de modificar chapters.ts (añadir / eliminar / reordenar capítulos, o cambiar la longitud de notes.ts de algún capítulo), incrementa STORAGE_KEY en presentation/src/hooks/useStepper.ts (ej. web-slides-cursor-v1 → v2), para evitar que el cursor persistido apunte a un paso que ya no existe.
Fase 3 — Presentación / Exportación
El proceso detallado está en references/PRESENTING.md. Puntos clave:
- Presentación en vivo:
npm run dev→ pantalla completa del navegador (F11) → avanzar con clic / teclas de dirección. - Navegación por teclado:
← →/ espacio para avanzar;Home/Endpara ir al principio/final; teclas numéricas1-9para saltar a un capítulo; PresionaPpara abrir la ventana del presentador (ventana independiente: libreto + vista previa en vivo + cronómetro, ambas ventanas sincronizadas); PresionaNpara abrir/cerrar la superposición de notas (superpuesta en la ventana actual, solo para ensayo — ⚠️ se compartirá si compartes pantalla). - Forma correcta de proyectar sin que se vea el libreto: Presiona
Ppara abrir la ventana del presentador → en el software de videoconferencia, selecciona "Compartir una ventana / pestaña" y elige la ventana principal de diapositivas (no "Compartir toda la pantalla") → la ventana del presentador solo la ves tú, el cambio de diapositivas sincroniza ambas ventanas, también funciona con un solo monitor. - Distribución offline / proyección más estable:
npm run build→npm run preview, o despliega la carpetadist/. - Exportación (opcional): Capturas de pantalla progresivas en PNG, o "Imprimir como PDF" desde el navegador paso a paso.
Al finalizar la Fase 2, informa activamente al usuario: las diapositivas están listas, el servidor de desarrollo se ejecuta en localhost:5174, puedes presentar en vivo / proyectar; Presiona P para abrir la ventana del presentador y ver el libreto (al proyectar, solo comparte la ventana principal de diapositivas, el público no lo ve), presiona N para la superposición de notas de ensayo (se compartirá si proyectas).
Diez principios (lista de una frase)
El desarrollo completo está en las secciones correspondientes de references/CHAPTER-CRAFT.md — consulta allí al escribir los capítulos, esto es solo un índice.
| # | Principio | Una frase |
|---|---|---|
| 1 | Lienzo fijo 16:9 | Contenido 1920×1080 + transform scale, sin responsividad |
| 2 | Contador de pasos global | El capítulo es una función pura del paso, sin temporizadores |
| 3 | Cada paso ocupa toda la pantalla | if (step === N) return <FullScene /> |
| 4 | Compás lógico = paso | Un compás = un paso = una idea enfocada |
| 5 | Controles esquineros ocultos | Barra de progreso con opacidad 0 por defecto; notas ocultas por defecto (se abren con N) |
| 6 | Escenario sin cromo | Sin header / footer / número de página / barra de marca |
| 7 | Animaciones impulsadas por el contenido | Primero busca una acción interna, solo si no hay, usa animaciones de entrada como respaldo; usa micro-movimientos continuos con moderación |
| 8 | Revelación múltiple punto por punto | 1 elemento = 1 paso, prohibido mostrar N elementos a la vez con stagger |
| 9 | Mismo tema en toda la presentación | No cambiar el color de fondo entre capítulos; colores / fuentes van por tokens, el resto de escalas son libres en cada capítulo |
| 10 | Principio de doble fuente | El outline define el ritmo, el material define la densidad de la imagen (aterrizando en el pool de información) |
🎤 En modo deck, los principios 3 "cada paso ocupa toda la pantalla" y 8 "1 elemento = 1 paso" se relajan a: una página = un capítulo, paso = construcción progresiva en la misma página (los elementos permanecen en pantalla y aparecen gradualmente); el resto de principios se mantienen. Ver arriba "Dos perfiles de densidad".
Consulta rápida de feedback común del usuario
Al recibir feedback, primero identifica en qué capa está (ritmo / visual / contenido / código), luego modifica la porción mínima, no rehagas el capítulo entero:
- Ritmo: Demasiado rápido / demasiado lento / poca información → dividir / fusionar pasos (ajustar simultáneamente la longitud de
notes.ts+ elif (step===N)del capítulo) - Visual: Estilo incorrecto / huele a IA → volver a CHAPTER-CRAFT.md "Evitar olor a IA" + "Estética básica de presentación"
- Contenido: Pantalla demasiado vacía / pocos detalles → volver al pool de información + el párrafo de
materialdel capítulo (principio de doble fuente) - Código: Error / token no funciona → volver a CHAPTER-CRAFT.md "Restricciones mínimas de código"
Recursos relacionados
Marcados con "cuándo leerlos" para evitar leer todo de una vez:
| Archivo | Cuándo leerlo | Contenido |
|---|---|---|
references/OUTLINE-FORMAT.md | Lectura obligatoria en Fase 1.2 | Especificación de campos de outline.md, convenciones de nomenclatura, división de capítulos, pool de información, notas por paso |
references/CHAPTER-CRAFT.md | Única entrada de lectura obligatoria en Fase 2.4 para cada capítulo | Requisitos de demostración visual / revelación progresiva / selección de contenido / doble fuente (outline+material) / estética de presentación / evitar olor a IA / restricciones mínimas de código (incluye notes.ts) / referencia de duración / auto-revisión de finalización |
references/EXAMPLES/ | Opcional — ver la estructura | Ejemplos de estructura de capítulos (hook / list-reveal / case-tech-review); no son plantillas para copiar |
references/THEMES.md | Al seleccionar / crear / modificar temas | Contrato completo de tokens + lista de temas integrados + flujo de creación |
references/PRESENTING.md | Leer solo en Fase 3 | Pantalla completa, navegación por teclado, presionar N para notas, exportar PDF / capturas de pantalla |
themes/ | Consultar durante Checkpoint Plan / Fase 1.2 | Temas integrados (cada uno con theme.json + tokens.css) |
scripts/scaffold.sh | Ejecutar una vez en Fase 2.1 | Scaffolding de proyecto con un solo comando |
Este skill es una adaptación de
web-video-presentation(autor ConardLi) — se eliminaron el libreto / audio / grabación de pantalla, se conservó toda la metodología visual y el sistema de temas, especializándose en diapositivas HTML para presentaciones en vivo.