claude-code-arcane 2.0.0 → 2.2.0

package/skills/vault-tidy/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: vault-tidy
+description: "Aplica los arreglos que reporto /vault-audit con approval item por item: linkear huerfanas, resolver nombres duplicados, cancelar tareas arrastradas, completar frontmatter y archivar. Nunca borra. Triggers: limpiar el vault, arreglar huerfanas, vault tidy, aplicar el audit, ordenar el vault, resolver links roto."
+argument-hint: "[orphans | broken | duplicates | tasks | frontmatter | archive | all]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash, Write, Edit
+---
+
+# Vault Tidy - Aplicar los arreglos
+
+Sos la única skill del profile que edita notas existentes en volumen, y por eso la más peligrosa. Cada cambio se propone y se aprueba: no hay modo batch, no hay "arreglo todo y te cuento después".
+
+Categoría a arreglar: `$ARGUMENTS` (default: preguntar cuál, nunca `all` por omisión)
+
+Aplica la rule `vault-conventions`.
+
+**Rutas por rol:** los destinos se nombran por rol y la ruta real de cada uno sale del `## Rutas` del `CLAUDE.md` del vault. Los defaults entre paréntesis solo aplican si el vault no declara otra cosa.
+
+## Fase 1 - Antes de tocar nada
+
+1. **Ubicar el vault** y leer su `CLAUDE.md`: el contrato de frontmatter y la estructura salen de ahí, no de tus defaults.
+2. **Verificar git.** Si el vault es un repo y el árbol está sucio, parar y pedir commit primero. Esta skill es la que más justifica tener git: es el único undo real de una corrida de 30 ediciones.
+3. **Correr `/vault-audit`** y trabajar sobre esos hallazgos. Nunca decidir a ojo qué arreglar.
+4. **Acotar la corrida.** Si el usuario pidió `all`, proponer partirla por categoría y arrancar por la de mayor impacto. Una corrida de 200 ediciones no se puede revisar y por lo tanto no se puede aprobar de verdad.
+
+## Fase 2 - Los arreglos, por categoría
+
+### `duplicates` - Nombres duplicados
+El más urgente: dos archivos con el mismo nombre hacen que todo `[[link corto]]` a ese nombre resuelva impredecible.
+
+Para cada par: mostrar las dos notas y proponer renombrar la menos linkeada, o fusionarlas si son la misma cosa. **El rename lo hace el usuario en Obsidian**, no vos: Obsidian actualiza los wikilinks cuando el rename pasa dentro de la app, y desde el filesystem se rompen en silencio. Tu entregable acá es la lista de renames a hacer y el orden.
+
+### `orphans` - Huérfanas
+Para cada huérfana: leerla, proponer el hub o la nota desde donde linkearla, y agregar el link **en el hub**, no en la huérfana. El link entrante es el que la hace encontrable.
+
+Si varias huérfanas son del mismo tema, el arreglo no es linkearlas una por una: es crear el hub que falta con `/hub-note` y linkearlas desde ahí. Decilo antes de empezar a parchear.
+
+### `broken` - Links roto
+Clasificar cada uno antes de tocarlo:
+
+- **Typo:** el target existe con otro nombre. Corregir el link.
+- **Intención:** la nota no existe todavía y el link es un recordatorio. **Se deja.** Un link roto intencional es una nota pendiente, no un error, y borrarlo destruye información.
+- **Basura:** link a algo que ya no aplica. Quitar el link, dejar el texto.
+
+Preguntá cuál es cuando no se pueda deducir del contexto. No adivines.
+
+### `tasks` - Tareas arrastradas
+Para cada tarea abierta en un día que ya cerró: marcarla `- [-]` en su día original y preguntar si sigue vigente. Si sigue, crearla en la nota del proyecto o en el dump de hoy. Nunca mover la original.
+
+### `frontmatter` - Contrato
+Completar los campos ausentes del contrato del vault. `created` se deduce del nombre del archivo si tiene fecha, o del mtime; `type` se deduce de la carpeta. Si no se puede deducir, preguntar. **Nunca sobrescribir un `created` que ya existe**, aunque parezca incorrecto: es dato histórico.
+
+### `archive` - Archivar
+Mover al rol `archive` (default `04_Archive/`) lo que el usuario confirme cerrado, preservando el nombre. **Nunca borrar nada.** El movimiento va con la misma advertencia que el rename: si hay notas que linkean a la que se mueve, avisar cuáles y dejar que el usuario lo haga desde Obsidian.
+
+## Fase 3 - Aplicar y reportar
+
+1. Proponer los cambios en una tabla: nota, qué cambia, por qué. Agrupar los mecánicos idénticos para no hacer 40 preguntas, y preguntar uno por uno los que requieren criterio.
+2. Aplicar solo lo aprobado, con `Edit` sobre citas textuales para no tocar nada alrededor.
+3. Reportar qué se cambió y qué quedó pendiente, y recordar el commit.
+
+Tidy COMPLETE cuando los cambios aprobados están aplicados y el resto quedó explícitamente pendiente, no olvidado.
+
+## Reglas
+
+- **Nunca borrar una nota.** Archivar.
+- **Nunca renombrar ni mover desde el filesystem** sin avisar que rompe wikilinks: proponé que lo haga el usuario desde Obsidian.
+- Nada de ediciones en masa sin approval, ni siquiera las triviales.
+- No tocar el rol `templates` (default `Templates/`) ni `.obsidian/`.
+- No reescribir contenido del usuario: agregás links y frontmatter, no editás su prosa.
+- Sin guiones largos.
+
+## Handoff
+
+Con los arreglos aplicados, volver a correr `/vault-audit` para confirmar que los números se movieron: si un hallazgo sigue igual, el arreglo no era el correcto. Si la corrida dejó al descubierto temas sin hub, el siguiente paso es `/hub-note`.

package/skills/voice-pipeline/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: voice-pipeline
+description: "Pipeline de voz: script de VO, casting, sesiones de grabacion, naming y batch processing, localizacion, lipsync y barks. Usar para: dialogo grabado, voice over, doblaje, localizacion de voz, gestion de assets de VO."
+category: "audio"
+argument-hint: "[script | casting | naming | loc | barks]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+# voice-pipeline — Voz y Localización
+
+Gestiona el ciclo completo de voz grabada: del script al asset integrado y localizado.
+
+La voz es el área de audio donde los errores son **más caros**: rehacer una sesión de grabación cuesta dinero y agenda de actores, y un error de naming multiplicado por 12 idiomas es inmanejable a mano.
+
+## Cuándo usar
+
+- Preparar un script de VO para grabación
+- Definir naming y estructura antes de recibir assets
+- Planificar localización a varios idiomas
+- Gestionar barks (chatter de combate) y su variación
+- El pipeline de VO se desordenó y hay que reorganizarlo
+
+## Input
+
+1. Leer audio bible (dirección de voz si existe) y el guion narrativo
+2. Determinar: cuántos idiomas, cuántos personajes, si hay lipsync
+3. Preguntar al usuario: presupuesto de grabación, si hay actores ya contratados, y plataforma de destino
+
+---
+
+## Naming — la decisión más importante
+
+**El naming se define antes de grabar una sola línea.** Renombrar 4.000 archivos × 12 idiomas después no es una tarea, es un proyecto.
+
+Patrón recomendado:
+
+```
+vo_<personaje>_<contexto>_<id>_<variante>
+vo_kira_combat_taunt_003_a
+vo_kira_story_ch02_017
+```
+
+**Requisitos del patrón:**
+- **ID estable y único** — nunca se reusa, ni si la línea se corta. Los huecos son gratis; renumerar no
+- **Sin espacios ni acentos** — sobrevive a cualquier filesystem y a batch scripts
+- **El idioma NO va en el nombre del archivo** — va en la ruta o en el bank de idioma. Así el mismo nombre resuelve en cualquier locale
+- **Ordenable alfabéticamente** en el orden en que se usa
+- **Longitud acotada** — algunas plataformas tienen límites de path
+
+El ID es la llave que une script, sesión de grabación, asset, subtítulo y traducción. Si cambia en algún punto, el vínculo se rompe.
+
+## Script de VO
+
+Lo que el actor y el director necesitan por línea:
+
+| Campo | Por qué |
+|---|---|
+| **ID** | La llave de todo el pipeline |
+| **Personaje** | |
+| **Texto** | Exacto, es lo que se graba y se subtitula |
+| **Contexto** | Qué pasó antes; sin esto la actuación es a ciegas |
+| **Dirección** | Emoción, intensidad, a quién le habla |
+| **Restricción de duración** | Si tiene que calzar en una animación o un hueco de gameplay |
+| **Tomas pedidas** | Cuántas variantes de intención |
+
+**El contexto es lo que más se omite y lo que más arruina sesiones.** Un actor grabando líneas sueltas en orden alfabético, sin saber a quién le habla ni qué acaba de pasar, entrega material que no sirve y hay que volver a convocarlo.
+
+**Orden de grabación:** por personaje y por escena, no por ID. Agrupar además por intensidad emocional — dejar los gritos para el final de la sesión, porque desgastan la voz y arruinan lo que venga después.
+
+## Casting
+
+- **Rango, no solo timbre** — el personaje que grita en el acto tres necesita un actor que pueda gritar sin perder la voz
+- **Distinguibilidad** — dos personajes que suenan parecido confunden en un juego donde el jugador no siempre ve quién habla. Test: escuchar sin ver
+- **Disponibilidad para pickups** — siempre hay pickups. Un actor imposible de reconvocar es un riesgo de producción
+- **Consistencia entre idiomas** — el casting de localización debería mantener el *rol tímbrico*, no imitar al actor original
+
+## Barks
+
+El chatter de combate tiene reglas propias porque se escucha muchísimo:
+
+- **Muchas variantes por intención** — mínimo 5-8 por tipo. Un bark repetido es lo primero que el jugador nota
+- **Cortos** — 0.5 a 2 s. Un bark largo se pisa con el gameplay
+- **Cooldown global por personaje y por tipo** — dos enemigos gritando lo mismo a la vez suena a bug
+- **Prioridad baja** — un bark nunca debe tapar diálogo narrativo ni feedback del jugador
+- **Bus separado** de `Dialogue` para que no duckeen la música (ver `/audio-mix`)
+- **Interrumpibles** — si el personaje muere a mitad del bark, se corta
+
+## Localización
+
+| Decisión | Recomendación |
+|---|---|
+| Estructura | Un bank o carpeta por idioma, mismos nombres de archivo adentro |
+| Idioma en runtime | Se resuelve cargando el bank del locale, sin lógica en gameplay |
+| Fallback | Idioma base si falta el asset — nunca silencio |
+| Expansión de texto | El alemán y el español crecen 20-35% sobre el inglés: los huecos de tiempo tienen que tolerarlo |
+| Subtítulos | Mismo ID que el audio. Un ID sin subtítulo es un bug de accesibilidad |
+| Sin doblar | Idiomas con subtítulo solo: definir explícitamente cuáles y que la mezcla lo contemple |
+
+**La expansión de texto es el problema práctico más común.** Una línea que calza justo en inglés se pasa 30% en alemán, y si hay una animación fija o un hueco de gameplay, no entra. Presupuestar el hueco contra el idioma más largo del target, no contra el inglés.
+
+## Procesamiento por lotes
+
+El VO llega en crudo y necesita el mismo tratamiento en miles de archivos. Lo que debe ser automatizado, no manual:
+
+1. **Recorte de silencios** con umbral consistente
+2. **Normalización de loudness** a un target común
+3. **De-noise / de-click** si la fuente lo pide
+4. **Fades** de entrada y salida cortos
+5. **Verificación**: sample rate, bit depth, canales, duración vs restricción
+6. **Reporte** de los que no cumplen
+
+El paso 5 y 6 son los que hay que exigir: sin verificación automática, los assets que no cumplen se descubren en integración.
+
+## Lipsync
+
+- **Basado en fonemas** (extraído del audio o del texto) o **basado en amplitud** (más barato, mucho peor)
+- Si hay lipsync, el **texto tiene que coincidir exactamente** con lo grabado — una improvisación del actor rompe la sincronía
+- La localización necesita lipsync regenerado por idioma, o aceptar el desfasaje explícitamente
+- Los pickups tienen que regenerar el lipsync de la línea afectada
+
+---
+
+## Proceso
+
+1. **Definir el naming** y congelarlo. Este paso primero, sin excepción
+2. **Armar el script** con contexto y dirección por línea
+3. **Planificar las sesiones** por personaje/escena, con los gritos al final
+4. **Definir la estructura** de localización y el fallback
+5. **Definir el pipeline** de batch con su paso de verificación
+6. **Definir barks** con variantes, cooldown y bus
+7. **Escribir** — preguntar "¿Escribo el pipeline a `<path>`?" antes de usar Write
+
+---
+
+## Verdict
+
+- **READY** — naming congelado, script con contexto y dirección, estructura de localización con fallback, pipeline de batch con verificación automática
+- **CONCERNS** — el pipeline existe pero el script no tiene contexto por línea, o la expansión de texto no se presupuestó, o los barks no tienen cooldown
+- **BLOCKED** — el naming no está definido: cualquier grabación antes de eso genera trabajo que se va a rehacer
+
+## Anti-patterns
+
+> → Read references/anti-patterns.md
+
+## Next steps
+
+- `/audio-mix` para el bus de diálogo y el ducking
+- `/audio-spec` para el contrato de eventos de barks (concurrencia y cooldown)
+- `/audio-audit` para verificar los assets entregados contra el spec
+- `/middleware-integration` para los banks de idioma

package/skills/voice-pipeline/references/anti-patterns.md

@@ -0,0 +1,69 @@
+# Voice Pipeline — Anti-patterns
+
+## Grabar antes de definir el naming
+
+El error más caro del pipeline. Renombrar 4.000 archivos × 12 idiomas, y actualizar script, subtítulos y referencias en el middleware, no es una tarea: es un proyecto. El naming se congela primero.
+
+## Idioma en el nombre del archivo
+
+`vo_kira_line_003_es.wav` obliga a lógica de resolución de nombre en runtime. El idioma va en la ruta o en el bank; el nombre del archivo es idéntico en todos los locales.
+
+## Renumerar IDs
+
+Se corta una línea y se renumeran las siguientes para "que quede ordenado". Se rompe el vínculo con subtítulos, traducciones y assets ya grabados. Los huecos en la numeración son gratis.
+
+## Script sin contexto
+
+El actor graba líneas sueltas en orden alfabético sin saber a quién le habla ni qué acaba de pasar. El material no sirve y hay que reconvocarlo. El contexto por línea es obligatorio.
+
+## Grabar en orden de ID
+
+El orden es por personaje y por escena. Y los gritos al final de la sesión: desgastan la voz y arruinan todo lo que venga después.
+
+## Casting por timbre solamente
+
+El personaje que grita en el acto tres necesita un actor con rango para gritar sin perder la voz. Y si dos personajes suenan parecido, el jugador que no ve quién habla se confunde.
+
+## Actor imposible de reconvocar
+
+Siempre hay pickups. Un actor sin disponibilidad futura es un riesgo de producción, no un detalle de contrato.
+
+## Presupuestar los huecos contra el inglés
+
+El alemán y el español crecen 20-35%. Una línea que calza justo en inglés no entra en alemán, y si hay animación fija, no hay arreglo. Presupuestar contra el idioma más largo del target.
+
+## Fallback a silencio
+
+Falta el asset en un idioma y no suena nada. El fallback es el idioma base, siempre.
+
+## Subtítulo sin el mismo ID
+
+Si el subtítulo no comparte la llave con el audio, mantener los dos sincronizados pasa a ser manual. Y una línea sin subtítulo es un bug de accesibilidad, no un pendiente.
+
+## Barks con pocas variantes
+
+Un bark repetido es lo primero que el jugador nota. Mínimo 5-8 por intención.
+
+## Barks sin cooldown
+
+Tres enemigos gritan la misma frase simultáneamente y suena a bug. Cooldown global por personaje y por tipo.
+
+## Barks en el bus de diálogo
+
+Cada bark de combate duckea la música. Bus separado.
+
+## Barks que no se interrumpen
+
+El personaje muere y su grito sigue sonando desde un cadáver.
+
+## Batch sin verificación
+
+Procesar miles de archivos sin un paso que valide sample rate, canales y duración deja que lo que no cumple se descubra en integración, cuando ya es tarde.
+
+## Lipsync con texto que no coincide
+
+El actor improvisó y el texto de referencia quedó viejo. La sincronía se rompe y nadie sabe por qué. El texto grabado y el de referencia son el mismo o el lipsync miente.
+
+## Localización sin regenerar lipsync
+
+O se regenera por idioma, o se acepta el desfasaje explícitamente como decisión. Lo que no se puede es descubrirlo en certificación.

package/skills/xlsx-generator/scripts/formula_check.py

@@ -27,6 +27,8 @@ Exit code:
     1 — errors detected (or file cannot be opened)
 """
 
+from __future__ import annotations
+
 import sys
 import zipfile
 import xml.etree.ElementTree as ET

package/skills/xlsx-generator/scripts/libreoffice_recalc.py

@@ -21,6 +21,8 @@ Exit codes:
     1 — LibreOffice found but recalculation failed (timeout, crash, bad file)
 """
 
+from __future__ import annotations
+
 import subprocess
 import sys
 import shutil

package/skills/xlsx-generator/scripts/xlsx_add_column.py

@@ -24,6 +24,8 @@ IMPORTANT: Run on an UNPACKED directory (from xlsx_unpack.py).
 After running, repack with xlsx_pack.py.
 """
 
+from __future__ import annotations
+
 import argparse
 import copy
 import os

package/skills/xlsx-generator/scripts/xlsx_insert_row.py

@@ -26,6 +26,8 @@ IMPORTANT: Run on an UNPACKED directory (from xlsx_unpack.py).
 After running, repack with xlsx_pack.py.
 """
 
+from __future__ import annotations
+
 import argparse
 import os
 import re

package/skills/xlsx-generator/scripts/xlsx_reader.py

@@ -17,6 +17,8 @@ Exit codes:
     1 — file not found / unsupported format / encoding failure
 """
 
+from __future__ import annotations
+
 import sys
 import json
 import argparse

package/skills/zettel/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: zettel
+description: "Crea una nota atomica en el vault a partir de una idea, un fragmento del dump o una nota de proyecto, con el criterio de cuando algo merece nota propia y a que linkearla. Triggers: nota atomica, zettel, esto merece nota propia, crear nota permanente, graduar esta idea, nota de concepto."
+argument-hint: "[idea | ruta#seccion | dump YYYY-MM-DD]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+
+# Zettel - Nota atómica
+
+Creás una nota que contiene **una** idea, escrita para que se entienda sola en dos años y linkeada al resto del vault. La mitad del trabajo es decidir si la nota tiene que existir.
+
+Idea o fuente: `$ARGUMENTS`
+
+Aplica la rule `vault-conventions`.
+
+**Rutas por rol:** los destinos se nombran por rol y la ruta real de cada uno sale del `## Rutas` del `CLAUDE.md` del vault (leelo antes de escribir). Los defaults entre paréntesis solo aplican si el vault no declara otra cosa.
+
+## Fase 1 - Decidir si merece nota propia
+
+Una idea merece nota atómica propia cuando pasa **las tres**:
+
+1. **Es verdadera fuera del contexto que la produjo.** Si solo tiene sentido dentro del proyecto donde apareció, es una nota de proyecto y se queda ahí.
+2. **La linkearías desde otra nota.** Si no se te ocurre ni un lugar desde donde apuntar a esto, todavía no es conocimiento: es un registro.
+3. **El título puede afirmar algo.** "Los índices parciales pagan en tablas con lecturas sesgadas" es una idea. "Postgres" es un tema, y los temas son hub files, no notas atómicas.
+
+Si falla alguna, decirlo y proponer el destino real: se queda en el dump, va a la nota del proyecto, o va al `## Historial` de un hub. Verdict de esta fase: PASS solo si las tres se cumplen. No crear la nota para no dejar al usuario con las manos vacías: una nota atómica de más ensucia el grafo para siempre.
+
+## Fase 2 - Buscar duplicados
+
+Antes de escribir, buscar duplicados con `/vault-recall` si está disponible (rankea, y encuentra la nota que usó otro nombre), o `Grep` en `<atomic>` (default `03_Resources/`) por los términos del título y sus sinónimos obvios. Si ya hay una nota que cubre la idea:
+
+- **Misma idea:** proponer ampliar la nota existente en vez de crear otra. Es el caso más frecuente y el que evita el vault con cinco notas del mismo concepto bajo cinco nombres.
+- **Idea relacionada pero distinta:** crear la nueva y linkear ambas explícitamente, con una línea de por qué se distinguen.
+
+## Fase 3 - Escribir
+
+Con approval sobre el título y el destino, crear la nota en `<atomic>` (default `03_Resources/`) desde `<templates>/Atomic.md`:
+
+- **Título como afirmación**, no como etiqueta. Es el nombre del archivo y lo que vas a ver en el autocompletado de links dentro de tres años.
+- **La idea en las palabras del usuario**, no en las de la fuente. Si es una cita, va entre comillas con su fuente; el cuerpo de la nota es la reformulación.
+- **Sección `## Por qué me importa`:** una o dos líneas sobre qué problema del usuario toca. Es lo que separa una nota atómica de un resumen de Wikipedia. Si el usuario no lo dijo, preguntar en una línea, no inventarlo.
+- **Sección `## Relacionado`:** al menos un `[[wikilink]]`, siempre. Si no hay a qué linkear, falta el hub del tema: crearlo con `/hub-note` antes de cerrar esta nota.
+- **Sección `## Fuente`:** el clip, el libro, la conversación, o "propia" si salió del usuario.
+- **`status` del frontmatter:** `seed` si la nota queda como semilla a propósito, `provisional` si ya tiene cuerpo. **Nunca pongas `evergreen` vos:** eso lo decide el usuario cuando la nota deja de moverse, y es lo que hace que el audit no la reporte como stale.
+
+Si la idea vino de una nota de proyecto o de un dump, **la fuente no se vacía**: la línea original se queda donde estaba y se le agrega el link a la nota nueva.
+
+## Fase 4 - Conectar
+
+1. Linkear la nota desde el hub del tema (sección `## Notas` del hub). El link del hub a la nota es el que la hace encontrable.
+2. Si la nota discute o contradice otra nota atómica, linkearlas entre sí con una línea de por qué. Las conexiones entre notas atómicas son laterales y sí son bidireccionales: es el único caso donde la regla de "links hacia arriba" no aplica, porque acá no hay jerarquía.
+
+Nota COMPLETE cuando existe, tiene al menos un link entrante desde un hub y al menos uno saliente.
+
+## Reglas
+
+- Una idea por nota. Si necesitás dos `##` que no se relacionan, son dos notas.
+- Nunca vaciar la fuente de la que salió la idea.
+- No crear la nota si falla el criterio de graduación, aunque el usuario lo haya pedido: explicá por qué y proponé el destino correcto. Si insiste, se crea.
+- Sin guiones largos.
+
+## Handoff
+
+Con la nota creada, el siguiente paso es `/hub-note` si el tema todavía no tiene hub, o volver a `/review-dump` si esto salió en medio de procesar un día. Al cierre de la semana `/review-weekly` va a levantar la nota como parte de lo que creció.