claude-code-arcane 2.0.0 → 2.1.0

package/skills/second-brain/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: second-brain
+description: "Entry point del segundo cerebro en Obsidian. Crea o adopta un vault (PARA + Zettelkasten + hub files), escribe su CLAUDE.md, detecta que plugins hay instalados, conecta otros proyectos al mismo vault y rutea al skill correcto. Triggers: second brain, segundo cerebro, setup vault obsidian, organizar mi vault, empezar vault, adoptar mi vault."
+argument-hint: "[setup | adopt | status | next | link]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash, Write, Edit
+---
+
+# Second Brain - Vault Orchestrator
+
+Sos el punto de entrada del segundo cerebro. Tu trabajo es: ubicar (o crear) el vault, entender en que estado esta, y rutear al skill correcto. No hacés todo vos, orquestás.
+
+Aplica la rule `vault-conventions` en toda escritura.
+
+## Idioma
+
+Comunicación con el usuario en **español**. Las notas del vault van en el idioma en que el usuario escribe sus dumps: detectalo del contenido existente y no lo cambies.
+
+## Ubicar el vault
+
+En este orden: flag `--vault <path>`, env `OBSIDIAN_VAULT`, o el directorio actual si contiene `.obsidian/`. Si no hay ninguno, preguntar antes de asumir. Un directorio sin `.obsidian/` no es un vault: es una carpeta con markdown, y hay que avisarlo.
+
+## El vault
+
+```
+CLAUDE.md              contrato del vault: estructura, frontmatter, reglas de link
+hot.md                 cache de contexto reciente, lo reescribe /review-dump
+_inbox/                captura cruda, un archivo por dia (YYYY-MM-DD dump.md)
+Reflect/
+  Daily/               sintesis del dia, la crea /review-dump
+  Weekly/              retrospectiva semanal
+  Monthly/             patrones y balance del mes
+01_Projects/           con deadline o resultado definido            [PARA]
+02_Areas/              responsabilidades continuas                  [PARA]
+03_Resources/          notas atomicas, plano, sin subcarpetas       [Zettelkasten]
+04_Archive/            cerrado, nunca borrado                       [PARA]
+Hubs/                  una nota por entidad que importa
+Bases/                 vistas .base
+Templates/             plantillas del usuario
+```
+
+Ese árbol es el **default del `setup`**, no una imposición: el `## Rutas` del `CLAUDE.md` del vault mapea cada rol (`inbox`, `daily`, `hubs`...) a la carpeta que lo cumple, y los skills leen ese mapeo. Un vault adoptado conserva sus nombres y todo sigue funcionando.
+
+Dos frameworks, dos capas: **PARA es la capa de navegación** (toda nota tiene una casa) y **Zettelkasten es la capa de conocimiento** (las notas atómicas viven planas en `03_Resources/` y se conectan por links). Los **hub files** son el tejido entre las dos: una nota por entidad que importa (persona, herramienta, concepto, empresa) que acumula conocimiento con el tiempo.
+
+Las carpetas agrupan por propósito, los links agrupan por significado: una nota vive en una carpeta y linkea a muchas.
+
+## Detección de capacidades
+
+Antes de generar cualquier vista o sintaxis que dependa de un plugin, leer `.obsidian/core-plugins.json` y `.obsidian/community-plugins.json` y adaptar:
+
+| Si está | Usar para | Si no está |
+|---|---|---|
+| `bases` (core, Obsidian 1.9+) | dashboards y vistas agregadas (`.base`) | tabla markdown estática en el dashboard |
+| `dataview` | campos inline y texto computado que Bases no expresa | reformular la vista para que la exprese Bases |
+| `obsidian-tasks-plugin` | sintaxis de fechas y prioridad en tareas | checkboxes markdown planos |
+| `templater-obsidian` | templates de alta frecuencia (daily) | los skills escriben el archivo directo |
+| `omnisearch` | ofrecerlo para búsqueda difusa desde la UI de Obsidian | `/vault-recall`, que rankea sin depender de plugins |
+
+Nunca mencionar en una nota una sintaxis de un plugin que el usuario no tiene instalado: queda como texto roto en la vista de lectura. Registrar el resultado de la detección en el `CLAUDE.md` del vault para no repetirla cada sesión.
+
+## Modos
+
+### `setup` - Crear el vault
+1. Confirmar el path del vault y si ya existe `.obsidian/` (si no existe, avisar que Obsidian tiene que abrirlo una vez para inicializarse).
+2. Correr la detección de capacidades.
+3. Crear el árbol de carpetas.
+4. Copiar los templates de `references/templates/` a `Templates/` del vault.
+5. Escribir el `CLAUDE.md` del vault desde `references/templates/vault-CLAUDE.md`, completando **el `## Rutas`** (rol a carpeta), el contrato de frontmatter y los plugins detectados. El `## Rutas` no es decorativo: es de donde todos los demás skills sacan dónde escribir.
+6. Si hay `bases`, crear `Bases/Dashboard.base` con las vistas de tareas abiertas y notas recientes (delegar la sintaxis a `/obsidian-bases`).
+7. Crear `hot.md` desde `references/templates/hot.md`, vacío. Es el caché que abre las sesiones siguientes (ver abajo).
+8. Si el usuario escribe código, crear `codebases.md` desde su template: es el puente del vault al repo, y lo que evita que la arquitectura se copie al vault.
+9. **Construir el índice** para que la primera búsqueda y el primer review no paguen la indexación completa:
+   ```bash
+   python .claude/skills/vault-recall/scripts/vault_index.py "<vault>" refresh
+   ```
+10. **Ofrecer el hook de validación** (opcional, ver abajo).
+11. Verificar que el vault sea un repo git; si no lo es, recomendarlo y explicar por qué (es el undo de cualquier corrida). Preguntar además si el vault se sincroniza y, si la respuesta es sí, aplicar las reglas de sync de abajo **antes** de escribir nada más.
+
+Pedir approval antes de escribir. Verdict: vault READY cuando existen el árbol, los templates y el `CLAUDE.md` con su `## Rutas`.
+
+### `adopt` - Adoptar un vault existente
+Para un vault ya armado, con o sin estructura coherente. No migra nada por su cuenta.
+
+1. Mapear lo que hay: `Glob` de carpetas de primer nivel, conteo de notas por carpeta, campos de frontmatter en uso (`Grep`), convención de nombres de las notas periódicas, tags más usados.
+2. **Mapear rol a carpeta**, que es el entregable central de este modo. Para cada rol (`inbox`, `daily`, `weekly`, `monthly`, `atomic`, `hubs`, `projects`, `areas`, `archive`, `templates`), proponer qué carpeta del vault lo cumple hoy, y marcar `(no usa)` los que no existen. Confirmar el mapeo con el usuario item por item: es la traducción de la que dependen todos los demás skills, y un rol mal mapeado hace que escriban en la carpeta equivocada sin error visible.
+3. Correr `/vault-audit` con los flags que salen de ese mapeo (`--exempt` para `templates` y `archive`, `--require` con los campos de frontmatter que el vault ya usa) para tener métricas reales y no hallazgos falsos.
+4. Reportar el mapeo y proponer **una de dos** rutas, con el costo de cada una:
+   - **Adoptar la estructura existente:** escribir el `CLAUDE.md` con el `## Rutas` que acabás de mapear. Cero movimiento de archivos, cero links roto. Es la opción por default.
+   - **Migrar a la estructura de `setup`:** plan explícito de qué carpeta va a dónde, ejecutado por `/vault-tidy` con approval item por item, en un repo git limpio.
+5. Escribir el `CLAUDE.md` de la ruta elegida, con el `## Rutas` completo. Nunca mover archivos en este modo.
+6. Construir el índice (`vault_index.py refresh`) pasando el mapeo: `--role hubs=<carpeta> --role atomic=<carpeta> ...`.
+
+Verdict: vault READY cuando el `CLAUDE.md` describe las convenciones reales del vault, no las ideales, y su `## Rutas` cubre los diez roles o los marca como no usados.
+
+### `status` - Dónde estoy
+1. Leer `hot.md` primero: son 40 líneas y responden "dónde estaba" sin abrir nada más. Si está vacío o desactualizado, seguir igual y decirlo.
+2. Leer el `CLAUDE.md` del vault para resolver los roles.
+3. Correr `vault_index.py "<vault>" inventory --format text`: ya devuelve los dumps sin daily, el último weekly y monthly, y los hubs con sus alias. Es una llamada en vez de varios `Glob`, y no crece con el vault.
+4. Reportar eso más las tareas abiertas y los proyectos sin actividad reciente.
+5. Recomendar la acción de mayor impacto.
+
+### `next` - Qué hago ahora
+Según el estado, recomendar el skill siguiente (ver routing).
+
+### `link` - Conectar otro proyecto al vault
+Para usar el mismo segundo cerebro desde cualquier repo, sin duplicar notas.
+
+1. Confirmar el path del vault y que el proyecto actual no sea el vault mismo.
+2. Leer `references/cross-project.md` y proponer el snippet, con el path real completado.
+3. Con approval, agregarlo al `CLAUDE.md` **del proyecto actual** (crear el archivo si no existe). Nunca se toca el vault en este modo.
+4. Explicar las dos reglas que hacen que esto funcione: la cascada de lectura (`hot.md` → búsqueda → hub → nota) y que **el vault no se lee para preguntas generales de programación**. Sin la segunda, cada consulta paga el costo del vault sin recibir nada.
+
+Verdict: proyecto READY cuando su `CLAUDE.md` declara el path, la cascada y el límite de escritura.
+
+## El puente al código (`repos:`)
+
+Una nota de hub o de proyecto que tenga código declara `repos:` en su frontmatter, y `codebases.md` traduce cada repo a su path local, cómo se corre y si tiene un grafo consultable. Es la dirección inversa de `/second-brain link`: ese modo hace que un repo lea el vault, esto hace que el vault sepa dónde está el repo.
+
+La regla que lo sostiene es **el vault apunta, no copia**: la arquitectura vive en el repo y se desactualiza el día que alguien mergea. Y si el repo tiene un grafo de código, consultarlo es la primera parada antes de mandar subagentes a explorar: un relevamiento cuesta del orden de 100k tokens, una consulta al grafo uno o dos mil.
+
+## El caché caliente (`hot.md`)
+
+Un archivo corto en la raíz del vault con dónde estabas: en qué trabajás, qué notas cambiaron, qué hilos siguen abiertos, qué tareas viven. Lo reescribe `/review-dump` al cerrar el día y lo lee `/second-brain status`, además de cualquier otro proyecto conectado con `link`.
+
+Idea tomada de `AgriciDaniel/claude-obsidian`, y es la que resuelve el agujero del ciclo: los tres reviews devuelven algo **cuando vos los pedís**. El caché devuelve algo al abrir la sesión, sin pedirlo.
+
+Cuatro reglas, duras porque es lo único del vault que se reescribe sin preguntar:
+
+- **Techo de 40 líneas.** Si no entra, hay que resumir más, no agrandar el techo.
+- **Nada de secretos ni transcripciones crudas**, aunque aparezcan en un dump.
+- **Ninguna afirmación sin su link.** El caché no crea conocimiento, apunta al que existe.
+- **Se reescribe completo.** Un caché al que se le agrega al final es un log, y un log nadie lo lee.
+
+Es descartable por diseño: si contradice una nota, la nota gana, y borrarlo no pierde nada porque se regenera.
+
+## Sync: dos reglas que evitan el 90% de los problemas
+
+Si el vault se sincroniza (Drive, iCloud, Dropbox, Obsidian Sync, git), dos cosas rompen de forma reproducible:
+
+1. **`.obsidian/` no se sincroniza.** Es config por máquina (plugins, tema, layout) y es la fuente número uno de conflictos. El patrón que lo resuelve es tener la raíz del vault local y meter el contenido compartido adentro por symlink:
+
+   ```
+   ~/ObsidianVault/          raiz local, nunca se sincroniza
+   ├── .obsidian/            TU config, queda local
+   └── contenido/            symlink a la carpeta sincronizada
+   ```
+
+   Obsidian sigue el symlink y lee las notas; la config nunca sale de tu máquina. Si el vault es solo tuyo y usás git, la alternativa es `.gitignore` con `.obsidian/`, `.vault-index.json` y `.trash/`.
+
+2. **Un solo transporte.** Nunca dos mecanismos de sync sobre la misma carpeta (Drive + Obsidian Sync, o iCloud + git con auto-commit): producen reversiones aleatorias que después nadie puede explicar.
+
+Y si el vault se comparte con otras personas: **un escritor por nota**. Ningún sync mergea markdown; el segundo que guarda genera una copia en conflicto. Este profile asume vault personal, y ese es su límite honesto: para equipo hace falta declarar dueño por nota y aceptar que la co-edición no existe.
+
+## Hook de validación (opcional)
+
+El profile trae un `PostToolUse` que revisa cada nota escrita en el vault: frontmatter presente, `created` y `type` declarados, y al menos un `[[wikilink]]` salvo en los dumps. Avisa por stderr y **nunca bloquea la escritura**.
+
+Sirve para lo que los skills no cubren: las notas que escribís a mano o desde otra sesión. Para activarlo, agregar a `.claude/settings.json` **del vault** el contenido de `.claude/skills/second-brain/hooks/hooks.json`:
+
+```json
+"PostToolUse": [
+  {
+    "matcher": "Write|Edit",
+    "hooks": [
+      { "type": "command", "command": "bash .claude/skills/second-brain/hooks/validate-note.sh", "timeout": 5 }
+    ]
+  }
+]
+```
+
+Es opt-in a propósito y va en el settings del vault, no en el del repo: un hook que corre en cada `Write` de cualquier proyecto es peso que nadie pidió. Ofrecelo en el `setup`, explicá que es solo un warning, y respetá el no.
+
+## Routing
+
+| Situación | Skill |
+|---|---|
+| No hay vault | `/second-brain setup` |
+| Vault existente sin `CLAUDE.md` | `/second-brain adopt` |
+| Capturar algo ahora, sin pensar dónde va | `/brain-dump` |
+| Procesar el dump del día y crear el daily | `/review-dump` |
+| Cerrar la semana | `/review-weekly` |
+| Cerrar el mes | `/review-monthly` |
+| Una idea del dump merece nota propia | `/zettel` |
+| Una entidad se repite en varios dumps | `/hub-note` |
+| Guardar un artículo o página web | `/vault-clip` |
+| Encontrar algo que ya escribiste | `/vault-recall` |
+| Usar el vault desde otro proyecto | `/second-brain link` |
+| Saber qué tan sano está el vault | `/vault-audit` |
+| Aplicar los arreglos que propuso el audit | `/vault-tidy` |
+| Dudas de sintaxis Obsidian, Bases o Canvas | `/obsidian-markdown`, `/obsidian-bases`, `/obsidian-canvas` |
+
+## Ciclo estándar
+
+Durante el día: `/brain-dump` cuantas veces haga falta (o escribir directo en `_inbox/YYYY-MM-DD.md`).
+A la noche: `/review-dump` clasifica, actualiza hubs y crea el daily.
+Fin de semana: `/review-weekly`. Fin de mes: `/review-monthly`.
+Cada tanto: `/vault-audit` y, si hace falta, `/vault-tidy`.
+
+## Reglas
+
+- Nunca reorganizar carpetas ni renombrar notas sin approval: rompe `[[wikilinks]]` en silencio.
+- La captura tiene que quedar sin fricción. Si el usuario tiene que decidir dónde va algo mientras lo escribe, el sistema ya falló.
+- No apilar frameworks. PARA + Zettelkasten + hub files es el techo; agregar GTD o CODE encima es la causa número uno de que estos sistemas se abandonen.
+- Un plugin de más es deuda: no recomendar ninguno que el vault no necesite para lo que el usuario efectivamente hace.
+- Máximo accionable: el usuario siempre termina sabiendo qué skill correr next.
+
+## Handoff
+
+Pedí approval antes de escribir o sobrescribir archivos del vault. Cuando el vault queda READY, el siguiente paso es `/brain-dump` para la primera captura, y `/review-dump` a la noche para cerrar el ciclo completo por primera vez.

package/skills/second-brain/hooks/hooks.json

@@ -0,0 +1,16 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash .claude/skills/second-brain/hooks/validate-note.sh",
+            "timeout": 5
+          }
+        ]
+      }
+    ]
+  }
+}

package/skills/second-brain/hooks/validate-note.sh

@@ -0,0 +1,85 @@
+#!/usr/bin/env bash
+# PostToolUse guard for notes written into an Obsidian vault.
+#
+# Warns, never blocks: a note half-written is still worth keeping, and a hook
+# that rejects writes turns capture into a fight. Everything here is a warning on
+# stderr and the exit code is always 0.
+#
+# Only fires for .md files that live under a directory containing .obsidian/, so
+# it stays silent in a code repo even when the profile is installed there.
+set +e
+
+VAULT_MARKER=".obsidian"
+
+find_vault_root() {
+  local dir="$1"
+  while [[ -n "$dir" && "$dir" != "/" && "$dir" != "." ]]; do
+    [[ -d "$dir/$VAULT_MARKER" ]] && { echo "$dir"; return 0; }
+    local parent
+    parent=$(dirname "$dir")
+    [[ "$parent" == "$dir" ]] && break
+    dir="$parent"
+  done
+  return 1
+}
+
+frontmatter_of() {
+  # Lines between the opening --- on line 1 and the next ---. Empty if the note
+  # has no frontmatter at all.
+  awk 'NR==1 && $0!="---" {exit} NR==1 {next} /^---$/ {exit} {print}' "$1" 2>/dev/null
+}
+
+main() {
+  local INPUT FILE
+  INPUT=$(cat 2>/dev/null) || true
+  FILE=$(echo "$INPUT" | grep -oE '"file_path"\s*:\s*"[^"]*"' | head -1 | sed 's/.*"file_path"\s*:\s*"//;s/"$//') || true
+
+  [[ -z "$FILE" ]] && return 0
+  [[ "$FILE" != *.md ]] && return 0
+  [[ ! -f "$FILE" ]] && return 0
+
+  # Windows paths arrive backslash-escaped inside the JSON payload.
+  FILE=$(echo "$FILE" | sed 's|\\\\|/|g; s|\\|/|g')
+  [[ ! -f "$FILE" ]] && return 0
+
+  local ROOT REL
+  ROOT=$(find_vault_root "$(dirname "$FILE")") || return 0
+  REL=${FILE#"$ROOT"/}
+
+  # Templates are hollow and unlinked by design; vault config is not a note.
+  case "$REL" in
+    Templates/*|*/Templates/*|.obsidian/*) return 0 ;;
+  esac
+
+  local FM
+  FM=$(frontmatter_of "$FILE")
+
+  if [[ -z "$FM" ]]; then
+    echo "WARN [vault] $REL has no frontmatter: the vault contract expects created and type" >&2
+    return 0
+  fi
+
+  local MISSING=""
+  echo "$FM" | grep -qE '^created:' || MISSING="created"
+  echo "$FM" | grep -qE '^type:' || MISSING="${MISSING:+$MISSING, }type"
+  [[ -n "$MISSING" ]] && \
+    echo "WARN [vault] $REL is missing frontmatter field(s): $MISSING" >&2
+
+  # A raw dump is allowed to have no links: /review-dump is what adds them.
+  local TYPE
+  TYPE=$(echo "$FM" | grep -E '^type:' | head -1 | sed 's/^type:[[:space:]]*//;s/["'\'']//g')
+  case "$TYPE" in
+    dump|"") return 0 ;;
+  esac
+  case "$REL" in
+    _inbox/*) return 0 ;;
+  esac
+
+  if ! grep -q '\[\[' "$FILE" 2>/dev/null; then
+    echo "WARN [vault] $REL has no wikilink: an unlinked note is an orphan the day it is written" >&2
+  fi
+}
+# stderr is left alone on purpose: it is the whole output of this hook. Some
+# hooks in hooks/ swallow it; here that would make the guard invisible.
+main
+exit 0

package/skills/second-brain/references/cross-project.md

@@ -0,0 +1,57 @@
+# Un vault, todos los proyectos
+
+El vault no sirve solo cuando estás sentado en él. Sirve cuando estás en otro repo y necesitás algo que ya pensaste. Esta es la receta para que cualquier proyecto lea el mismo segundo cerebro, sin duplicar nada.
+
+Adaptado del patrón de `AgriciDaniel/claude-obsidian` (MIT), con la cascada de lectura y la regla de exclusión que son la parte que importa.
+
+## El snippet
+
+Pegar esto en el `CLAUDE.md` **del otro proyecto**, con el path real:
+
+```markdown
+## Segundo cerebro
+
+Vault: `~/ruta/al/vault`
+
+Cuando necesites contexto que no está en este repo, en este orden y parando en
+cuanto alcance:
+
+1. `hot.md` del vault: caché de contexto reciente, corto por diseño.
+2. `python <vault>/.claude/skills/vault-recall/scripts/vault_index.py "<vault>" search "<consulta>"`
+   para encontrar las notas relevantes por relevancia, no por keyword.
+3. El hub del tema en `Hubs/`, y de ahí a las notas que linkea.
+4. Solo entonces, la nota específica.
+
+NO leas el vault para preguntas generales de programación. Es memoria personal,
+no documentación técnica: si la respuesta está en los docs del lenguaje o en este
+repo, el vault no aporta y solo gasta contexto.
+
+Nunca escribas en el vault desde este proyecto sin que yo lo pida explícitamente.
+```
+
+## Por qué la cascada, y por qué en ese orden
+
+Cada escalón es más caro que el anterior. `hot.md` son 40 líneas y cubre "qué estaba haciendo". La búsqueda cuesta una llamada y devuelve rutas, no contenido. El hub cuesta una lectura y te da el mapa del tema. La nota específica es lo único que trae texto completo.
+
+Sin la cascada, un agente con acceso al vault hace lo que haría cualquiera sin instrucciones: `Glob` de todo y leer lo que parezca relacionado. En un vault de mil notas eso es la sesión entera gastada antes de empezar.
+
+## Por qué la regla de exclusión es la línea más importante
+
+`NO leas el vault para preguntas generales de programación`.
+
+Sin eso, el vault se convierte en un lugar más donde buscar antes de responder cualquier cosa, y cada consulta paga el costo sin recibir nada. El vault aporta cuando la respuesta depende de **tu** historia: una decisión que tomaste, una persona con la que hablaste, algo que ya te pasó. Para saber cómo funciona un `Promise.all`, no.
+
+## Escritura desde otro proyecto
+
+Por default, **solo lectura**. Un proyecto que escribe en el vault sin que se lo pidas mete notas sin frontmatter, sin links y sin que nadie las revise, que es exactamente el material del que están hechas las huérfanas.
+
+Cuando quieras capturar algo al vault desde otro repo, hay dos caminos:
+
+- **Recomendado:** `/brain-dump` con `--vault <path>`. Va al dump del día, sin clasificar, y lo procesa el review a la noche como cualquier otra captura.
+- **Si te molesta pasar el path:** un servidor MCP de Obsidian (por ejemplo `@bitbonsai/mcpvault`) te deja tocar el vault desde cualquier sesión. Cuesta una dependencia y latencia, y hay que aclarar en el `CLAUDE.md` del proyecto que solo se usa para capturar, no para reorganizar.
+
+## Lo que no hay que hacer
+
+- **No copiar notas del vault al repo.** Dos copias divergen y ninguna gana.
+- **No apuntar el proyecto a una subcarpeta del vault** para "acotar". Rompe la resolución de `[[wikilinks]]`, que es global al vault.
+- **No dejar que un proyecto corra `/vault-tidy` ni `/review-dump`.** Esos escriben en volumen y necesitan al usuario mirando. Desde otro repo, el vault se lee.

package/skills/second-brain/references/templates/Atomic.md

@@ -0,0 +1,22 @@
+---
+created: {{date:YYYY-MM-DD}}
+type: atomic
+tags: []
+---
+
+# <Título que afirma la idea, no que la nombra>
+
+<La idea en tus palabras, en un párrafo. Si necesitás dos títulos `##` que no se relacionan, son dos notas.>
+
+## Por qué me importa
+
+<Una o dos líneas: qué problema tuyo toca esto. Es lo que hace que la nota sea tuya y no un resumen.>
+
+## Relacionado
+
+- [[Hub del tema]]
+- <otras notas atómicas con las que discute o a las que refuerza>
+
+## Fuente
+
+<Link al clip, al libro, a la conversación. Si salió de tu cabeza, decilo.>

package/skills/second-brain/references/templates/Daily.md

@@ -0,0 +1,25 @@
+---
+created: {{date:YYYY-MM-DD}}
+type: daily
+tags: []
+---
+
+# {{date:YYYY-MM-DD}}
+
+Dump del día: [[{{date:YYYY-MM-DD}} dump]]
+
+## Qué pasó
+
+<Síntesis en 3 a 5 líneas, escrita por /review-dump a partir del dump. Hechos, no interpretación.>
+
+## Notas creadas
+
+<Links a las notas que salieron del dump de hoy.>
+
+## Tareas del día
+
+<Tareas que quedaron en este día, con su estado real. Las no hechas quedan como `- [-]`, no se mueven.>
+
+## Reflexión
+
+<Esta sección la escribe el usuario. Claude no la toca.>

package/skills/second-brain/references/templates/Dashboard.base

@@ -0,0 +1,70 @@
+filters:
+  and:
+    - '!file.inFolder("Templates")'
+    - '!file.inFolder("04_Archive")'
+
+formulas:
+  dias_sin_tocar: '(now() - file.mtime).days'
+
+properties:
+  status:
+    displayName: Madurez
+  formula.dias_sin_tocar:
+    displayName: "Dias sin tocar"
+  file.mtime:
+    displayName: Modificada
+
+views:
+  - type: table
+    name: "Semillas que no crecieron"
+    filters:
+      and:
+        - 'status == "seed"'
+        - "formula.dias_sin_tocar > 30"
+    order:
+      - file.name
+      - formula.dias_sin_tocar
+      - created
+    summaries:
+      formula.dias_sin_tocar: Average
+
+  - type: table
+    name: "Contradicciones abiertas"
+    filters:
+      - 'status == "contested"'
+    order:
+      - file.name
+      - created
+
+  - type: table
+    name: "Tocado esta semana"
+    limit: 30
+    filters:
+      - "file.mtime > now() - 7d"
+    order:
+      - file.mtime
+      - file.name
+      - status
+
+  - type: table
+    name: "Conocimiento por madurez"
+    filters:
+      - 'type == "atomic" || type == "hub" || type == "clip"'
+    groupBy:
+      property: status
+      direction: ASC
+    order:
+      - file.name
+      - type
+      - formula.dias_sin_tocar
+
+  - type: table
+    name: "Proyectos activos"
+    filters:
+      and:
+        - 'type == "project"'
+        - 'status != "cerrado"'
+    order:
+      - file.name
+      - status
+      - deadline

package/skills/second-brain/references/templates/Dump.md

@@ -0,0 +1,11 @@
+---
+created: {{date:YYYY-MM-DD}}
+type: dump
+tags: []
+---
+
+# {{date:YYYY-MM-DD}} dump
+
+<!-- Tirá todo acá. Sin tags, sin decidir dónde va, sin orden. Una línea por cosa.
+     Tareas como `- [ ] ...`. Lo clasifica /review-dump a la noche. -->
+

package/skills/second-brain/references/templates/Hub.md

@@ -0,0 +1,22 @@
+---
+created: {{date:YYYY-MM-DD}}
+type: hub
+tags: []
+aliases: []
+---
+
+# <Nombre de la entidad>
+
+<Qué es y por qué tiene una nota propia, en una o dos líneas.>
+
+## Estado actual
+
+<Lo que hay que saber hoy sobre esto. Esta sección se reescribe, no se acumula.>
+
+## Notas
+
+<Links a las notas atómicas y proyectos de este tema. Acá sí se acumula.>
+
+## Historial
+
+<Línea por evento, formato `- YYYY-MM-DD - qué pasó`, agregado por /review-dump cuando la entidad aparece en un dump. Lo más nuevo arriba.>

package/skills/second-brain/references/templates/Monthly.md

@@ -0,0 +1,29 @@
+---
+created: {{date:YYYY-MM-DD}}
+type: monthly
+tags: []
+---
+
+# {{date:YYYY-MM}}
+
+Weeklies del mes: <links a los weeklies>
+
+## Patrones
+
+<Lo que se repitió a lo largo del mes y no se ve en una sola semana.>
+
+## Logros
+
+<Lo que efectivamente se cerró, con link a la nota que lo respalda.>
+
+## Ideas para adelante
+
+<Semillas: lo que apareció este mes y merece seguimiento el mes que viene.>
+
+## Salud del vault
+
+<Resumen de la última corrida de /vault-audit: huérfanas, stale, tareas viejas abiertas.>
+
+## Reflexión
+
+<Esta sección la escribe el usuario.>

package/skills/second-brain/references/templates/Weekly.md

@@ -0,0 +1,29 @@
+---
+created: {{date:YYYY-MM-DD}}
+type: weekly
+tags: []
+---
+
+# {{date:YYYY}}-W{{date:ww}}
+
+Dailies de la semana: <links a los dailies existentes>
+
+## Temas de la semana
+
+<Los 3 a 5 temas que se repitieron, cada uno con los dailies donde aparece.>
+
+## Hilos abiertos
+
+<Lo que quedó sin cerrar y sigue vivo. Distinto de una tarea: es una pregunta o decisión pendiente.>
+
+## Tareas: hechas y no hechas
+
+<Conteo y detalle. Las no hechas se nombran, no se esconden.>
+
+## Notas que crecieron
+
+<Hub files y notas atómicas que recibieron contenido esta semana.>
+
+## Reflexión
+
+<Esta sección la escribe el usuario.>

package/skills/second-brain/references/templates/codebases.md

@@ -0,0 +1,37 @@
+---
+created: {{date:YYYY-MM-DD}}
+type: codebases
+---
+
+# Codebases
+
+Puente del vault al código. Las notas de hub y de proyecto declaran `repos:` en su frontmatter; esta tabla dice qué es cada repo y dónde está en esta máquina.
+
+**El vault apunta, no copia.** Acá no va arquitectura, ni estructura de carpetas, ni explicaciones de módulos: eso vive en el repo y se desactualiza el día que alguien mergea. Acá va solo lo que el repo no te puede decir: dónde está local, cómo se corre, y qué te vas a llevar puesto.
+
+| Repo | Path local | Rama | Cómo correr | Grafo | Notas |
+|---|---|---|---|---|---|
+| `<repo>` | `~/code/<repo>` | `main` | `npm run dev` | `graphify` | `<gotcha en una línea>` |
+
+## Antes de explorar un repo, consultá su grafo
+
+Si el repo tiene un grafo de código consultable, **esa es la primera parada, no un subagente explorando**. Un relevamiento de arquitectura con subagentes cuesta del orden de 100k tokens y minutos; una consulta al grafo cuesta uno o dos mil y es instantánea.
+
+```bash
+graphify query "que conecta X con Y" --budget 2000
+graphify explain "<Simbolo>"
+```
+
+Y si el repo tiene una capa curada de arquitectura (por ejemplo `exploracion/ARQUITECTURA.md`), leela después del grafo: ahí viven las decisiones y los gotchas que un AST no ve. Si tu cambio invalida algo de lo que documenta, actualizarla es parte del cambio.
+
+## Qué va en el vault y qué va en el repo
+
+| Pregunta | La responde |
+|---|---|
+| ¿Qué hace esto y para quién? | El vault: el hub del tema |
+| ¿Por qué está hecho así? | El vault: la decisión, en una nota atómica |
+| ¿Qué archivos toco? | El repo: el grafo |
+| ¿Qué se rompe si cambio esto? | El repo: el grafo |
+| ¿Cómo lo corro y qué me va a explotar? | Esta tabla |
+
+Si te encontrás copiando arquitectura al vault, la pregunta que estabas contestando era del repo.

package/skills/second-brain/references/templates/hot.md

@@ -0,0 +1,37 @@
+---
+type: cache
+updated: {{date:YYYY-MM-DD}}
+---
+
+# Contexto reciente
+
+> [!warning] Esto es un caché, no una nota
+> Lo reescribe `/review-dump` al cerrar el día. Si contradice a una nota, **la nota gana**. Se puede borrar sin perder nada: se regenera. No lo edites a mano, no lo linkees desde otras notas.
+
+## Dónde estoy
+
+<Dos o tres líneas: en qué está trabajando el usuario ahora. Reescrito cada vez, no acumulado.>
+
+## Cambió en los últimos días
+
+<Links a las notas creadas o tocadas, con una línea de qué cambió en cada una. Máximo 10.>
+
+## Hilos abiertos
+
+<Preguntas y decisiones pendientes, con link a donde aparecieron. Máximo 5. Un hilo que se cierra se saca de acá.>
+
+## Tareas vivas
+
+<Las tareas abiertas que siguen vigentes, con link a su nota. No las canceladas.>
+
+<!--
+Reglas de este archivo, y son duras porque es lo único del vault que un agente
+reescribe sin preguntar:
+
+- Techo de 40 lineas. Si no entra, es que hay que resumir mas, no agrandar el techo.
+- Nada de secretos, tokens, ni credenciales, aunque aparezcan en un dump.
+- Nada de transcripciones crudas ni de texto pegado de terceros.
+- Ninguna afirmacion sin su link a la nota que la respalda. Este archivo no crea
+  conocimiento: apunta al que ya existe.
+- Se reescribe completo, no se le agrega al final. Un caché que crece es un log.
+-->