Youtube-note-forge

YouTube Transcript v4.0.0

El tiempo de ejecución principal completo del producto es el plugin de escritorio youtube-note-reader de Obsidian. Es el propietario de la máquina de estados determinista, llama al modelo compatible con OpenAI configurado, ejecuta estos scripts, persiste el estado de la tarea y escribe la nota terminada en el Vault activo. La extensión de Chrome solo proporciona la URL del video actual y la Cookie del navegador. OpenCode sigue siendo un punto de entrada opcional solo para Skill y no es requerido por la instalación completa del navegador + Obsidian.

Use este Skill como una máquina de estados estricta. No improvise rutas de extracción alternativas.

Versión

Cuando el usuario solicite la versión actual, ejecute:

python .obsidian/skills/youtube-transcript/scripts/video_note.py --version

Devuelva la salida del comando. Nunca responda de memoria. Reporta la versión instalada, la ruta de origen y los valores SHA-256 de los archivos principales.

Flujo de trabajo fijo

Para cada URL, complete los siguientes pasos antes de pasar a la siguiente URL. Detenga todo el lote en el primer resultado de script no cero.

1. Extraer material fuente:

python .obsidian/skills/youtube-transcript/scripts/extract_transcript.py "<url>" --output-dir "YouTube video" --deadline 300

2. Leer la nota generada y su SRT. Cree un plan JSON con article_outline y frames. article_outline contiene 3-8 capítulos derivados del transcript; cada elemento tiene section_id, title, start, end, core_claims y learning_goal. Elija los fotogramas por valor de aprendizaje, normalmente un fotograma requerido por cada capítulo visualmente significativo más evidencia opcional para pasos o resultados distintos. La mayoría de los videos necesitan 6-14 fotogramas; 24 es solo el límite de seguridad estricto, nunca un objetivo. No cree múltiples puntos de tiempo casi idénticos solo para aumentar el recuento. Cada fotograma tiene section_id, timestamp, purpose y required. Use el mismo section_id para vincular cada captura de pantalla a su capítulo de resumen detallado. No renombre ni reescriba la nota todavía. No escriba scripts de prueba ni inspeccione formatos de video manualmente.
3. Extraer los fotogramas planificados exactamente una vez. Después de un resultado de material exitoso, este es el único comando ejecutable siguiente permitido:

python .obsidian/skills/youtube-transcript/scripts/extract_frames.py "<url>" --plan "<plan.json>" --note "<generated-note.md>" --output-dir "YouTube video" --deadline 120

4. Confirmar que el resultado del fotograma tiene status: ok, al menos una captura de pantalla y una ruta manifest real. El script escribe automáticamente frame_manifest en el YAML de la nota. Si falta alguno de estos, deténgase; no escriba la nota final ni sustituya la portada.
5. Renombrar y reescribir la nota generada in situ según references/note-contract.md. En ## 详细内容总结, use cada article_outline.title como un encabezado exacto de ###, explique sus afirmaciones principales e inserte cada fotograma exitoso requerido en su capítulo correspondiente con una explicación en chino. Para capturas de pantalla locales del vault, use siempre incrustaciones wiki de Obsidian como ![[YouTube video/assets/VIDEO_ID/frame.jpg]]; nunca use un objetivo Markdown sin escapar que contenga espacios. Solo las imágenes listadas en el manifiesto cuentan como capturas de pantalla.
6. Validar:

python .obsidian/skills/youtube-transcript/scripts/validate_note.py "<finished-note.md>"

7. Si la validación falla, edite esa nota solo una vez y ejecute el validador una vez más. Nunca ejecute extracción, escriba scripts temporales, inspeccione código de implementación ni diagnostique el comportamiento de la plataforma durante esta reparación. Si aún falla, deténgase y reporte los errores devueltos. Después de una validación exitosa, el validador elimina solo los borradores Markdown 待命名 - ... en la misma carpeta cuyo YAML url coincida exactamente con la nota final; los borradores interrumpidos no coincidentes permanecen disponibles para reanudar.

Política de fallos

PIPELINE_RESULT es la fuente de verdad. En status: error, deténgase inmediatamente y reporte la URL, etapa, código, mensaje, acción, URLs completadas y URLs no iniciadas.

Nunca responda a un fallo ejecutando otro descargador, un navegador, Puppeteer, extracción de cookies de Chrome/Edge, una búsqueda web, una grabación de audio o un segundo intento. El único reintento controlado está dentro de los scripts: una última verificación de Cookie conocida y una actualización de la URL del flujo de video durante la extracción de fotogramas objetivo.

ASR está deshabilitado por defecto. Use --allow-asr solo si el usuario acepta explícitamente la descarga de audio y el procesamiento más lento.

Requisitos visuales

• Las capturas de pantalla son evidencia, no decoración.
• Use demostraciones, interfaces, diagramas, parámetros, estados de comparación y resultados.
• El script de fotogramas primero usa un flujo remoto de 720p o inferior con encabezados de solicitud yt-dlp. Si la búsqueda remota falla, puede descargar solo un segmento acotado de 8 segundos alrededor de cada punto de tiempo planificado. Los segmentos temporales se eliminan inmediatamente y nunca se descarga un video completo para las capturas de pantalla.
• Un fallo de fotograma requerido o menos del 70% de cobertura del plan de fotogramas es un fallo duro.
• Una portada, miniatura, imagen copiada manualmente o incrustación duplicada nunca cuenta como fotograma clave.
• Mantenga los fotogramas planificados incluso cuando sus diseños generales se vean similares. El texto de terminal, código, diapositivas y cambios de estado de la interfaz de usuario son útiles. Rechace solo fotogramas efectivamente en blanco (negro/blanco); no use OCR, análisis de imagen con IA ni filtrado de duplicados perceptual.
• Nunca reclame finalización a menos que exista frame_manifest y cada fotograma del manifiesto requerido aparezca en ## 详细内容总结.
• No cree archivos Canvas.

Requisitos de la nota final

• Nombre de archivo: 中文标题 - English Title.
• El YAML contiene skill_version: 4.0.0, quality_profile_version: 1 y un frame_manifest válido escrito por extract_frames.py.
• El cuerpo comienza en ## 一句话摘要 sin un título H1 duplicado.
• Elimine del cuerpo final el estado de la fuente, la descripción del video, los índices de material visual, las advertencias de extracción, las instrucciones de la tarea y las secciones de autoverificación; el YAML ya lleva los metadatos de la fuente.
• Use chino primero; explique la terminología inglesa necesaria en el primer uso.
• Deje que el transcript determine el esquema del artículo y la profundidad. Las imágenes apoyan la explicación; nunca acorte ni omita contenido importante simplemente porque no esté disponible un fotograma coincidente.
• Haga coincidir la profundidad del artículo con la duración del video. Cada capítulo planificado necesita una explicación real, evidencia de video o ejemplo, y una implicación de aprendizaje clara. Evite relleno genérico y párrafos repetidos.
• Enlace el SRT al final. No pegue texto de transcript sin procesar.
• Elimine la lista de verificación de autoverificación antes de la finalización.