claude-code-arcane 2.0.0 → 2.2.0

package/skills/audio-mix/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: audio-mix
+description: "Mezcla de juego: jerarquia de buses, ducking y sidechain, mix states/snapshots, frequency masking, headroom y targets de loudness. Usar para: estructura de buses, ducking de dialogo, mix dinamico, resolver que el mix suena barroso."
+category: "audio"
+argument-hint: "[buses | ducking | states | loudness | review]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+# audio-mix — Mezcla Dinámica
+
+Diseña la estructura de buses y las reglas que deciden **qué se escucha cuando todo suena a la vez**.
+
+El mix de un juego no es un mix estático: es un sistema de reglas, porque no se sabe de antemano qué va a sonar simultáneamente.
+
+## Cuándo usar
+
+- Definir la arquitectura de buses del proyecto
+- El mix suena barroso, o el diálogo no se entiende
+- Falta control dinámico: momentos importantes no destacan
+- Cumplir targets de loudness de plataforma
+
+## Input
+
+1. Leer audio bible, sección 4 (frequency allocation) y 5 (mix hierarchy)
+2. Listar las categorías de audio del proyecto
+3. Preguntar al usuario: plataformas target, si hay diálogo, y si existe algún requisito de certificación
+
+---
+
+## Jerarquía de buses
+
+Estructura base que sirve para casi cualquier juego:
+
+```
+Master
+├── Music
+├── SFX
+│   ├── Player          (feedback de la acción del jugador)
+│   ├── World           (enemigos, props, entorno)
+│   └── Ambience
+├── Voice
+│   ├── Dialogue        (narrativa, crítico)
+│   └── Barks           (chatter de combate)
+└── UI
+```
+
+**Por qué esta forma:**
+- `Player` separado de `World` permite proteger el feedback de la acción del jugador cuando hay 40 enemigos
+- `Dialogue` separado de `Barks` permite duckear por diálogo importante sin que cada bark baje la música
+- `UI` afuera de `SFX` porque tiene su propio nivel (−18 a −24 dB) y su propio control de usuario
+- `Ambience` separado porque es lo primero que se sacrifica cuando el mix se llena
+
+**Cada bus necesita:** volumen base, control de usuario expuesto o no, y si va a reverb de zona.
+
+## Ducking
+
+Bajar una categoría cuando otra suena. Los casos reales:
+
+| Trigger | Qué duckea | Cuánto | Attack / Release |
+|---|---|---|---|
+| Diálogo | Music, Ambience | −6 a −9 dB | 50 ms / 400 ms |
+| UI crítico | Music, SFX | −3 a −6 dB | 20 ms / 200 ms |
+| Momento narrativo | Todo menos Voice | −12 dB | 200 ms / 800 ms |
+| Barks | nada, o −2 dB | mínimo | rápido |
+
+**El release siempre más largo que el attack.** Un release corto produce bombeo audible: la música sube y baja a cada palabra. 300-500 ms de release para diálogo es lo que suena natural.
+
+**El ducking no reemplaza al arreglo.** Si la música vive en 500 Hz-2 kHz y el diálogo también, hay que duckear tanto que se escucha. La solución es dejar ese rango libre en el arreglo (ver `/music-composition`, orquestación production-aware). El ducking es el ajuste fino, no la solución estructural.
+
+**Sidechain vs ducking por evento:** el ducking por evento (el middleware baja el bus cuando el evento está activo) es más predecible y más barato. El sidechain real (detectar la señal) responde mejor a diálogo de duración variable. Para VO grabado, ducking por evento alcanza.
+
+## Frequency masking
+
+Dos sonidos que ocupan la misma banda compiten, y el más fuerte gana. El EQ correctivo adelgaza todo; la solución es la **asignación de bandas** del audio bible.
+
+Cuando ya está producido y hay que arreglarlo:
+
+| Problema | Arreglo de mezcla |
+|---|---|
+| Diálogo tapado por música | EQ dinámico en Music: hueco en 1-3 kHz solo cuando hay VO |
+| Impactos sin peso | High-pass en Music y Ambience por debajo de 80 Hz |
+| Mix barroso | High-pass en todo lo que no necesita graves; casi nada necesita por debajo de 60 Hz |
+| UI perdido | Reducir el brillo de la percusión, no subir el UI |
+| Todo suena chico | Demasiadas fuentes; el problema es voice count, no EQ |
+
+## Mix states
+
+Snapshots de la mezcla que se activan por contexto. El mix dinámico es lo que hace que un juego suene "bien mezclado" en situaciones que nadie mezcló a mano.
+
+| Estado | Qué cambia |
+|---|---|
+| Exploration | Base |
+| Combat | Player y World arriba, Ambience abajo |
+| Cutscene | Voice arriba, todo lo demás abajo, sin UI |
+| Menu (pausa) | Todo salvo UI y Music muy abajo o silenciado |
+| Low health | Filtro en Music, tinnitus, resto atenuado |
+| Death | Corte o filtro extremo |
+
+**Interpolar entre estados**, nunca saltar. 200-500 ms según qué tan dramático sea el cambio. Y definir qué pasa si dos estados quieren activarse a la vez: prioridad explícita.
+
+## Headroom y loudness
+
+**Headroom:** dejar margen en el master para que los picos simultáneos no clippeen. El mix se hace apuntando a que el caso peor (explosión + música + diálogo) tenga espacio, no el caso promedio.
+
+**Targets de loudness.** La referencia de industria en juegos es **ASWG-R001** (Sony), que es la única especificación de una plataforma mayor:
+
+| Contexto | Loudness promedio | True peak máximo |
+|---|---|---|
+| Consola / home | **−23 LUFS** (±2) | **−1 dBTP** |
+| Portable / handheld | **−18 LUFS** | −1 dBTP |
+
+El target portable es más alto porque se juega en ambientes ruidosos y con speakers chicos.
+
+Notas de aplicación:
+- La medición es del **programa completo en gameplay representativo**, no de un asset aislado
+- Verificar los targets vigentes de cada plataforma antes de certificación: las recomendaciones se revisan (el promedio de ASWG estuvo también citado como −24 LKFS)
+- El true peak de −1 dBTP deja margen para la codificación lossy, que puede generar picos por encima del valor medido en PCM
+
+---
+
+## Proceso
+
+1. **Definir la jerarquía de buses** con sus volúmenes base y controles de usuario
+2. **Definir reglas de ducking** con attack/release y cuánto
+3. **Definir mix states** con sus transiciones y prioridades
+4. **Verificar masking** contra la frequency allocation del bible
+5. **Definir targets de loudness** por plataforma y cómo se van a medir
+6. **Escribir** — preguntar "¿Escribo el diseño de mezcla a `<path>`?" antes de usar Write
+
+### Verificación
+
+El mix se valida **jugando**, en el caso peor: máxima densidad de enemigos, con diálogo, con música de combate, en el dispositivo más chico del target. Si ahí se entiende el diálogo y se lee el feedback del jugador, el mix funciona.
+
+---
+
+## Verdict
+
+- **COMPLIANT** — buses definidos, ducking con release más largo que attack, mix states interpolados con prioridad, y loudness medido dentro del target de cada plataforma
+- **CONCERNS** — la estructura existe pero el loudness no se midió en gameplay real, o el ducking está tapando un problema de arreglo
+- **NON-COMPLIANT** — el loudness está fuera del target de plataforma, o hay clipping en el caso peor
+
+## Anti-patterns
+
+> → Read references/anti-patterns.md
+
+## Next steps
+
+- `/audio-audit` para medir loudness, picos y voice count en gameplay real
+- `/middleware-integration` para implementar buses, ducking y states
+- `/ui-sound-design` para el nivel del bus UI
+- `/music-composition` si el masking se tiene que resolver en el arreglo y no en la mezcla

package/skills/audio-mix/references/anti-patterns.md

@@ -0,0 +1,65 @@
+# Audio Mix — Anti-patterns
+
+## Mezclar en aislamiento
+
+Aprobar cada categoría por separado y esperar que el conjunto funcione. El mix se valida jugando el caso peor: máxima densidad, con diálogo, con música de combate, en el dispositivo más chico.
+
+## Release de ducking demasiado corto
+
+La música sube y baja a cada palabra y se escucha el bombeo. El release siempre más largo que el attack: 300-500 ms para diálogo.
+
+## Ducking como solución al masking
+
+Si la música y el diálogo viven los dos en 500 Hz-2 kHz, hay que duckear tanto que el efecto es audible. Eso se resuelve en el arreglo, dejando el rango libre. El ducking es ajuste fino.
+
+## Todo duckea a todo
+
+Barks duckeando música, UI duckeando SFX, ambiente duckeando barks. El resultado es un mix que respira todo el tiempo y nunca está quieto. Definir qué duckea a qué, y que sea poco.
+
+## Un solo bus de SFX
+
+Con 40 enemigos, el feedback de la acción del jugador se pierde entre el resto. Separar `Player` de `World` es lo que permite protegerlo.
+
+## Diálogo y barks en el mismo bus
+
+Cada bark de combate duckea la música. Separarlos permite duckear por diálogo importante nada más.
+
+## UI dentro de SFX
+
+El UI tiene otro nivel (−18 a −24 dB) y suele necesitar control de usuario propio. Metido en SFX, hereda un volumen que no le corresponde.
+
+## Mix states que saltan
+
+Cambiar de snapshot instantáneamente se escucha como un corte. Interpolar 200-500 ms según el cambio.
+
+## Estados sin prioridad
+
+Combat y Low health quieren activarse a la vez y el resultado depende del orden de evaluación. Prioridad explícita.
+
+## EQ correctivo en todo
+
+Adelgazar cada fuente con EQ hasta que dejen de pelear produce un mix delgado y sin peso. El problema de raíz es la asignación de bandas, o hay demasiadas fuentes sonando.
+
+## Confundir "suena chico" con problema de EQ
+
+Cuando todo suena chico, casi siempre hay demasiadas voces activas y ninguna tiene lugar. Es un problema de voice count, y el EQ no lo arregla.
+
+## Nada de headroom
+
+Mezclar apuntando al caso promedio y clippear cuando coinciden explosión, música y diálogo. El margen se calcula contra el peor caso.
+
+## Medir loudness en un asset aislado
+
+Los targets de LUFS son del programa completo en gameplay representativo. Medir un archivo no dice nada del cumplimiento.
+
+## Asumir un target sin verificar
+
+Los targets de plataforma se revisan. Confirmar el vigente antes de certificación en vez de confiar en un número memorizado.
+
+## Ignorar el true peak
+
+Un mix que llega a 0 dBFS en PCM puede generar picos por encima al codificarse en lossy. −1 dBTP existe por eso.
+
+## Mezclar solo con auriculares buenos
+
+El mix suena perfecto en los monitores del sound designer y se cae en el speaker de un handheld. Validar en el dispositivo más chico del target.

package/skills/audio-spec/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: audio-spec
+description: "SFX spec sheets y audio event lists: trigger, prioridad, concurrencia, cooldown, variaciones, propiedades espaciales. Usar para: especificar sonidos, event list por sistema, brief para sound designer."
+category: "audio"
+argument-hint: "[system-name | all | events]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+# audio-spec — SFX Specs & Event Lists
+
+Convierte dirección sonora en especificaciones que un sound designer externo puede producir sin más briefing, y en event lists que un programador puede implementar sin adivinar.
+
+Dos entregables distintos y complementarios:
+- **Spec sheet** — describe *el sonido*: cómo suena, cuánto dura, cuántas variantes
+- **Event list** — describe *el contrato*: qué lo dispara, con qué prioridad, cuántas instancias, qué parámetros recibe
+
+## Cuándo usar
+
+- Después de `/audio-bible` (la dirección tiene que existir primero)
+- Cuando vas a tercerizar producción de SFX y necesitás un brief cerrado
+- Cuando el código necesita saber qué eventos postear antes de que existan los assets
+- Antes de `/middleware-integration` — la event list es su input
+
+## Modos
+
+| Modo | Qué hace |
+|---|---|
+| `system-name` | Especifica un sistema concreto: spec sheets + event list de, por ejemplo, `combat` |
+| `all` | Barre todos los sistemas del proyecto, uno por vez |
+| `events` | Solo la event list, sin spec sheets. Para cuando el código necesita el contrato antes de que existan los assets |
+
+## Input
+
+1. Leer audio bible (paleta, frequency allocation, mix hierarchy, standards). Si no existe, avisar y ofrecer `/audio-bible` primero
+2. Identificar el sistema a especificar (combate, locomoción, UI, ambiente, props...) o `all`
+3. Leer el código/GDD del sistema para extraer los momentos que piden sonido
+4. Preguntar al usuario: nivel de detalle (spec completo vs event list sola) y si hay assets existentes que reusar
+
+---
+
+## Spec sheet — campos obligatorios
+
+Cada sonido lleva estos campos. Un campo vacío es una decisión que alguien va a tomar por vos:
+
+| Campo | Qué define | Ejemplo |
+|---|---|---|
+| **ID** | Nombre canónico, matchea naming del bible | `sfx_weapon_shotgun_fire` |
+| **Descripción** | Qué es, en una línea funcional | Disparo de escopeta de doble caño, seco, sin cola de reverb |
+| **Referencias** | 1-3 sonidos concretos con qué tomar de cada uno | — |
+| **Carácter frecuencial** | Dónde vive, contra la allocation del bible | Sub-punch 50-70 Hz + crack 3-5 kHz, vacío en mids |
+| **Duración** | Rango, no valor único | 180-260 ms |
+| **Envolvente** | Attack / body / tail explícitos | Attack <5 ms, body 60 ms, tail 120 ms |
+| **Rango de volumen** | Nivel relativo a la categoría | −6 dB a −3 dB del bus SFX |
+| **Propiedades espaciales** | 2D/3D, curva de atenuación, min/max distance | 3D, 2-40 m, log |
+| **Variaciones** | Cuántas variantes y qué randomización | 5 variantes, pitch ±3%, volumen ±1.5 dB |
+| **Prioridad** | Qué se cae primero bajo presión de voces | Alta (feedback de acción del jugador) |
+
+## Event list — campos obligatorios
+
+| Campo | Qué define |
+|---|---|
+| **Evento** | Nombre que postea el código |
+| **Trigger** | Condición exacta de gameplay que lo dispara |
+| **Sonidos** | Qué IDs de spec resuelve (uno o un container) |
+| **Concurrencia** | Máximo de instancias simultáneas + qué hacer al exceder (drop oldest / drop newest / reject) |
+| **Cooldown** | Mínimo entre disparos, para eventos que pueden spamearse |
+| **Parámetros** | RTPCs que recibe, con rango normalizado |
+| **Stop condition** | Cómo termina: one-shot, loop con stop explícito, o fade |
+
+**Concurrencia y cooldown no son opcionales.** Son la diferencia entre un sistema que sobrevive 40 enemigos en pantalla y uno que satura el voice budget. Todo evento que puede dispararse más de una vez por frame necesita ambos.
+
+---
+
+## Proceso
+
+1. **Barrer el sistema** — listar cada momento que pide sonido, incluyendo los negativos (dónde el silencio es la decisión)
+2. **Agrupar** — sonidos que comparten carácter van juntos; identificar qué puede ser variación de un mismo asset en vez de asset nuevo
+3. **Draftar** specs y event list del grupo
+4. **Presentar** al usuario para review
+5. **Escribir** — preguntar "¿Escribo el spec de `<sistema>` a `<path>`?" antes de usar Write
+
+No batchear sistemas: cerrar uno antes de abrir el siguiente.
+
+### Reducción de assets
+
+Antes de especificar N sonidos nuevos, preguntar si el caso se resuelve con variación o con síntesis. El caso canónico: 20 samples × 6 superficies × 3 intensidades = 360 archivos (~180 MB) vs footsteps procedurales (~50 KB) con variación infinita. Si el sistema es de alta frecuencia y muchas dimensiones, derivar a `/procedural-audio` antes de escribir el spec.
+
+---
+
+## Verdict
+
+Por sistema especificado:
+
+- **READY** — todo sonido tiene los 10 campos, todo evento tiene concurrencia y cooldown. Un externo puede producir y un programador puede implementar
+- **CONCERNS** — hay campos vacíos o eventos sin límites; listar cuáles
+- **BLOCKED** — falta el audio bible, o el sistema de gameplay no está definido lo suficiente para saber qué momentos existen
+
+## Anti-patterns
+
+> → Read references/anti-patterns.md
+
+## Next steps
+
+- `/middleware-integration` para implementar la event list en Wwise/FMOD
+- `/procedural-audio` para los sistemas de alta frecuencia que no conviene samplear
+- `/sfx-design` para profundizar el diseño de los sonidos hero
+- `/audio-audit` para verificar los assets entregados contra el spec

package/skills/audio-spec/references/anti-patterns.md

@@ -0,0 +1,45 @@
+# Audio Spec — Anti-patterns
+
+## Spec sin números
+
+"Impacto potente y satisfactorio" no es producible. Duración, envolvente, bandas de frecuencia y nivel relativo sí. Si el campo no tiene número o rango, no está especificado.
+
+## Duración como valor único
+
+"200 ms" fuerza al sound designer a mentir o a pedir aprobación. Un rango (180-260 ms) le da lugar a que el sonido termine donde tiene que terminar.
+
+## Eventos sin concurrencia
+
+El spec dice "sonido de casquillo al caer". Llegan 40 enemigos, 300 casquillos, el voice budget explota y el mix desaparece. Todo evento que puede dispararse más de una vez por frame necesita máximo de instancias y política de descarte.
+
+## Cooldown ausente en eventos de UI
+
+Navegación rápida en un menú dispara el mismo tick 15 veces en 200 ms. Suena como un glitch. Cooldown mínimo, siempre.
+
+## Una variante
+
+Un sonido sin variantes se vuelve audible como *sonido* en vez de como evento en unos 20 minutos de juego. Si el evento es frecuente, mínimo 4-5 variantes o randomización de pitch, y preferentemente ambas.
+
+## Pitch randomization exagerada
+
+±3% es variación. ±20% cambia el objeto: el arma parece otra arma. Rango chico y round-robin le gana a rango grande.
+
+## Specs 3D sin curva
+
+Marcar "3D" y no definir min/max distance ni forma de la curva deja la atenuación en el default del middleware, que casi nunca es el correcto. El sonido se oye a 200 m o desaparece a 3 m.
+
+## Especificar antes de decidir procedural
+
+Escribir 360 spec sheets de footsteps es trabajo perdido si la respuesta correcta era síntesis. Evaluar el eje frecuencia × dimensiones antes de especificar.
+
+## Event list sin stop condition
+
+Los loops son la fuente número uno de audio colgado. Todo sonido que loopea necesita decir explícitamente quién lo para y qué pasa si el objeto dueño se destruye primero.
+
+## Prioridades todas iguales
+
+Si todo es prioridad alta, el voice limiter descarta al azar y se cae el feedback de la acción del jugador antes que un ambiente lejano. Las prioridades solo sirven si están diferenciadas.
+
+## IDs que no siguen el naming del bible
+
+`shotgun2_FINAL_v3` rompe búsqueda, batch processing y automatización de banks. El ID sale del pattern del bible, sin excepciones.

package/skills/brain-dump/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: brain-dump
+description: "Captura sin friccion al dump del dia en el vault de Obsidian: tareas, ideas, links, transcripciones. Sin tags, sin decidir donde va. Triggers: anota, capturar, brain dump, tirame esto al vault, apunta esto, agregar al inbox, dump del dia."
+argument-hint: "[texto a capturar]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Write, Edit
+---
+
+# Brain Dump - Captura sin fricción
+
+Agregás lo que el usuario te pasa al dump del día y te callás. Este skill existe para que capturar cueste cero: el momento en que el usuario tiene que pensar "¿dónde va esto?", el sistema ya falló.
+
+Contenido a capturar: `$ARGUMENTS`
+
+Aplica la rule `vault-conventions`.
+
+**Rutas por rol:** el destino se nombra por rol (`inbox`, `templates`), y la ruta real sale del `## Rutas` del `CLAUDE.md` del vault. Los defaults entre paréntesis solo aplican si el vault no declara otra cosa.
+
+## Pasos
+
+1. **Ubicar el vault.** Flag `--vault <path>`, env `OBSIDIAN_VAULT`, o el directorio actual si contiene `.obsidian/`. Si no hay vault, decirlo en una línea y ofrecer `/second-brain setup`. No inventar una carpeta.
+
+2. **Resolver el rol `inbox`.** Leer el `## Rutas` del `CLAUDE.md` del vault. Es lo único que hace falta leer del contrato acá, y cuesta una lectura: escribir en `_inbox/` cuando el vault usa otra carpeta deja la captura en un lugar que ningún review va a mirar. Si el vault no tiene `CLAUDE.md`, usar el default y avisar en la misma línea de confirmación.
+
+3. **Abrir el dump de hoy.** `<inbox>/YYYY-MM-DD dump.md` (default `_inbox/`) con la fecha de hoy. El dump se llama `YYYY-MM-DD dump.md` y no `YYYY-MM-DD.md` a propósito: el daily de ese día ya se llama `YYYY-MM-DD.md`, y dos archivos con el mismo nombre hacen que `[[2026-07-28]]` resuelva de forma impredecible en todo el vault. Es la colisión que el audit reporta como `ambiguous_names`, y sin el sufijo pasaría todos los días. Si el vault ya tiene dumps con el nombre viejo, seguir su convención y avisarlo, en vez de partir la serie en dos.
+
+   Si no existe, crearlo desde `<templates>/Dump.md` (default `Templates/`), o con el frontmatter mínimo `created`, `type: dump`, `tags: []` si el template no está.
+
+4. **Agregar el contenido al final**, una línea por cosa, sin reordenar ni reescribir lo que ya había:
+   - Lo que suena a tarea va como `- [ ] <texto>`. Lo que suena a idea, nota o link va como `- <texto>`.
+   - URLs sueltas se dejan crudas, con el título de la página al lado solo si el usuario lo dio. No abrir la URL: eso es `/vault-clip`.
+   - Se preserva la redacción del usuario. No corregís su ortografía ni su registro, no resumís, no traducís.
+
+5. **Si no vino contenido en `$ARGUMENTS`**, preguntar qué capturar en una sola línea y esperar. No abrir un cuestionario.
+
+6. **Confirmar en una línea** qué se agregó y a qué archivo. Nada más: el usuario está en medio de otra cosa.
+
+## Approval
+
+La invocación del skill es la aprobación para agregar al dump de hoy: pedir confirmación en cada captura destruiría el punto del skill. Los límites son estrictos en cambio para todo lo demás: **pedí approval explícito antes de escribir fuera del rol `inbox`**, antes de editar líneas que ya estaban en el dump, y antes de crear cualquier nota en los roles `atomic` o `hubs`. Clasificar es trabajo de `/review-dump`, no de acá.
+
+## Reglas
+
+- No clasificar, no taggear, no linkear, no crear notas nuevas. Nada de eso pasa en la captura.
+- No juzgar el contenido ni sugerir mejoras. Es un dump, no un borrador.
+- Nunca reescribir ni reordenar lo que ya estaba en el archivo: solo append.
+- Sin guiones largos en lo que agregues de tu parte.
+- Si el usuario captura algo que claramente es una tarea de un proyecto que existe, **igual va al dump**. La ruteada la hace el review, así el usuario nunca decide en el momento.
+
+## Handoff
+
+Captura COMPLETE cuando el contenido está en el dump del día. A la noche, o cuando el usuario quiera cerrar el día, el siguiente paso es `/review-dump` para clasificar todo lo capturado y generar el daily.

package/skills/hub-note/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: hub-note
+description: "Crea o actualiza un hub file (MOC) del vault: una nota por entidad que importa (persona, herramienta, concepto, empresa) que acumula conocimiento y conecta PARA con Zettelkasten. Triggers: hub file, MOC, mapa de contenido, nota de entidad, crear hub de, actualizar hub, nota de persona."
+argument-hint: "[entidad] [--update]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+
+# Hub Note - Tejido conectivo del vault
+
+Un hub file es una nota por entidad que importa. No contiene conocimiento propio: contiene **el estado actual** de esa entidad y **los links** a todo lo que se sabe de ella. Es lo que hace que PARA (carpetas) y Zettelkasten (notas planas) convivan sin pelearse.
+
+Entidad: `$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 la entidad merece hub
+
+El criterio es la recurrencia, no la importancia: **la entidad apareció en tres dumps o notas distintas**. Antes de eso es una mención, y un hub por mención produce cientos de notas de una línea que nadie visita.
+
+1. Buscar la entidad con `/vault-recall` si está disponible, o `Grep` en los roles `inbox`, `daily` y `atomic` (defaults `_inbox/`, `Reflect/Daily/`, `03_Resources/`) por el nombre y sus variantes.
+2. Contar apariciones y reportarlas con los links.
+3. Si hay menos de tres, decirlo y proponer esperar. Si el usuario quiere el hub igual (una persona nueva en el equipo, un proyecto que arranca), se crea: la anticipación es un motivo válido, la duda no.
+
+Verdict: PASS si hay tres apariciones o una razón explícita del usuario.
+
+## Fase 2 - Buscar el hub existente
+
+`Glob` en `<hubs>` (default `Hubs/`) y revisar los `aliases` del frontmatter de los hubs que haya. Las entidades llegan con nombres distintos ("Educabot", "educabot", "EB"): si ya existe un hub para la entidad bajo otro nombre, **actualizar ese** y agregar el nombre nuevo a `aliases`. Nunca crear un segundo hub para la misma entidad: es el duplicado más caro del vault, porque parte el conocimiento en dos lugares que nadie reconcilia.
+
+## Fase 3 - Escribir
+
+Con approval, crear o actualizar el hub en `<hubs>` (default `Hubs/`) desde `<templates>/Hub.md`.
+
+Al **crear**:
+- Título: el nombre canónico de la entidad. Las variantes van a `aliases`.
+- Una o dos líneas de qué es y por qué tiene nota propia.
+- `## Estado actual`: lo que hay que saber hoy.
+- `## Notas`: links a las notas atómicas y proyectos del tema que ya existan (los que encontraste en la fase 1).
+- `## Historial`: una línea por aparición relevante, formato `- YYYY-MM-DD - qué pasó`, lo más nuevo arriba.
+- `status`: `seed` al crearlo, `provisional` cuando ya acumuló contenido. Un hub que el usuario mantiene al día puede quedar `evergreen`, pero lo marca él.
+- `repos:` si la entidad tiene código (una herramienta propia, un proyecto, un servicio). Es el puente al repo, y se traduce a path local en `codebases.md` del vault. **No copies arquitectura al hub:** el hub dice qué es y por qué, el repo dice cómo está hecho, y el que copia se desactualiza.
+
+Al **actualizar** (`--update`, o cuando el hub ya existe):
+- Agregar la entrada nueva al `## Historial`, sin duplicar una que ya esté con la misma fecha y el mismo contenido.
+- **`## Estado actual` se reescribe, no se acumula.** Es la sección que responde "qué sé hoy de esto"; si se convierte en un log, el hub deja de servir para lo único que sirve. Lo que se reemplaza y sigue siendo relevante baja al historial.
+- `## Notas`: agregar los links nuevos.
+
+## Fase 4 - Conectar
+
+- El hub linkea hacia las notas atómicas y los proyectos. Los dumps y dailies linkean **hacia** el hub. El hub no linkea a dumps ni a dailies: son registro, no conocimiento, y llenan el hub de ruido en un mes.
+- Si el hub cubre un tema amplio y ya pasó las 30 o 40 entradas en `## Notas`, proponer partirlo en sub-hubs por subtema. Un hub que nadie puede leer de arriba a abajo dejó de ser un mapa.
+
+Hub COMPLETE cuando tiene estado actual, al menos un link saliente, y las apariciones encontradas quedaron en el historial.
+
+## Reglas
+
+- Un hub por entidad. Los alias van al frontmatter, no a un hub nuevo.
+- El hub no acumula conocimiento propio: si querés explicar una idea, es una nota atómica (`/zettel`) linkeada desde acá.
+- Nunca borrar entradas del historial: si algo dejó de ser cierto, se agrega la entrada nueva.
+- Sin guiones largos.
+
+## Handoff
+
+Con el hub listo, el siguiente paso es `/zettel` para las ideas del tema que todavía no tienen nota propia, o volver a `/review-dump` si esto salió procesando el día. `/vault-audit` va a usar los hubs para distinguir una huérfana real de una nota que simplemente todavía no fue linkeada.