claude-code-arcane 1.4.0 → 2.1.0

package/skills/personal-brand/references/post-pillars.md

@@ -1,17 +1,17 @@
-# Post Pillars — Ángulos, hooks y formatos
+# Post Pillars - Ángulos, hooks y formatos
 
 Guía para generar ideas con sustancia por cada uno de los 4 pilares. Cada idea final = **hook + ángulo + formato**.
 
 ## Formatos disponibles
 
-- **Text post corto** — 1 idea, 3–6 líneas, hook fuerte.
-- **Lista / "X things"** — escaneable, alto guardado.
-- **Carrusel** — paso a paso o framework (si el usuario hace slides).
-- **Hot take / POV** — opinión con tensión, invita a debate.
-- **Story / mini-caso** — situación → acción → resultado (mini-STAR público).
-- **Pregunta** — abre conversación, sube engagement.
+- **Text post corto** - 1 idea, 3-6 líneas, hook fuerte.
+- **Lista / "X things"** - escaneable, alto guardado.
+- **Carrusel** - paso a paso o framework (si el usuario hace slides).
+- **Hot take / POV** - opinión con tensión, invita a debate.
+- **Story / mini-caso** - situación → acción → resultado (mini-STAR público).
+- **Pregunta** - abre conversación, sube engagement.
 
-## Pilar 1 — Builder credibility
+## Pilar 1 - Builder credibility
 
 Demostrar que entregás. Ángulos:
 - Un problema real que resolviste + el número de impacto.
@@ -21,7 +21,7 @@ Demostrar que entregás. Ángulos:
 
 Hooks ejemplo: *"Bajé la latencia de matchmaking 25%. El cambio que más movió la aguja no fue el que esperaba."*
 
-## Pilar 2 — Lessons from current role
+## Pilar 2 - Lessons from current role
 
 Aprendizajes concretos, no abstractos. Ángulos:
 - Un error que cometiste y qué cambiaste.
@@ -31,7 +31,7 @@ Aprendizajes concretos, no abstractos. Ángulos:
 
 Hooks ejemplo: *"Pasé 2 años optimizando lo que no importaba. Esto es lo que mido ahora."*
 
-## Pilar 3 — POVs on your domain
+## Pilar 3 - POVs on your domain
 
 Posicionarte como alguien que piensa el dominio. Ángulos:
 - Una tendencia y por qué estás de acuerdo / en contra.
@@ -41,7 +41,7 @@ Posicionarte como alguien que piensa el dominio. Ángulos:
 
 Hooks ejemplo: *"Todos dicen que [tendencia]. En producción, lo que veo es otra cosa."*
 
-## Pilar 4 — Behind-the-scenes del job search
+## Pilar 4 - Behind-the-scenes del job search
 
 Cercanía + a veces atrae ofertas directas. Usar con medida (no quejas). Ángulos:
 - Qué buscás y por qué (señal clara para recruiters).
@@ -53,9 +53,9 @@ Hooks ejemplo: *"Estoy buscando mi próximo rol como [rol]. Esto es exactamente
 
 ## Secuenciación (90 días)
 
-- **Días 1–30 (autoridad):** ~70% pilares 1–3, ~30% pilar 2. Casi nada de "busco trabajo" todavía — primero construís credibilidad.
-- **Días 31–60 (visibilidad + señal):** introducir pilar 4 (qué buscás), mantener 1–3. Empezar outreach (`/cold-outreach`) apoyado en los posts.
-- **Días 61–90 (conversión):** mezclar los 4, más casos de builder credibility, CTAs suaves hacia conversaciones.
+- **Días 1-30 (autoridad):** ~70% pilares 1-3, ~30% pilar 2. Casi nada de "busco trabajo" todavía - primero construís credibilidad.
+- **Días 31-60 (visibilidad + señal):** introducir pilar 4 (qué buscás), mantener 1-3. Empezar outreach (`/cold-outreach`) apoyado en los posts.
+- **Días 61-90 (conversión):** mezclar los 4, más casos de builder credibility, CTAs suaves hacia conversaciones.
 
 ## Anti-patrones
 

package/skills/portfolio-site/SKILL.md

@@ -7,7 +7,7 @@ user-invocable: true
 allowed-tools: Read, Glob, Grep, Bash, Write, Edit, WebFetch
 ---
 
-# Portfolio Site — Portfolio web desde el source-of-truth
+# Portfolio Site - Portfolio web desde el source-of-truth
 
 Generás o actualizás un **portfolio web personal** a partir de un único source-of-truth (`portfolio/Datos Portfolio Web.md` en el career workspace, derivado del perfil maestro). La regla: **el contenido se edita primero en el `.md`** y de ahí se sincroniza al sitio.
 
@@ -19,7 +19,7 @@ Convención: **valores en inglés** (van directo al sitio) y meta-instrucciones
 
 ## Modos
 
-### `sync` — Actualizar un portfolio existente
+### `sync` - Actualizar un portfolio existente
 Para cuando ya hay un repo de portfolio (ej. una React SPA con el contenido en `src/pages/*.js`, `src/data/*`, o similar).
 
 1. Leer el source-of-truth y el repo destino.
@@ -28,10 +28,10 @@ Para cuando ya hay un repo de portfolio (ej. una React SPA con el contenido en `
 4. Aplicar los cambios al sitio respetando su arquitectura y estilo de código existentes.
 5. Verificar (build/preview) y resumir el diff.
 
-### `scaffold` — Crear un portfolio nuevo
+### `scaffold` - Crear un portfolio nuevo
 Para cuando no hay sitio todavía.
 
-1. Preguntar el stack preferido (default sugerido: **sitio estático simple** — HTML/CSS o un framework liviano como Astro/Vite — fácil de hostear en GitHub Pages/Netlify).
+1. Preguntar el stack preferido (default sugerido: **sitio estático simple** - HTML/CSS o un framework liviano como Astro/Vite - fácil de hostear en GitHub Pages/Netlify).
 2. Preguntar secciones deseadas (hero, about, experiencia, proyectos, skills, contacto).
 3. Generar el proyecto consumiendo el source-of-truth como contenido.
 4. Configurar deploy (GitHub Pages / Netlify) si el usuario quiere.
@@ -39,18 +39,18 @@ Para cuando no hay sitio todavía.
 
 ## Secciones típicas
 
-- **Hero** — nombre, headline, bio corto, links (GitHub/LinkedIn/email público).
-- **About** — bio medio/largo.
-- **Experience** — roles con highlights.
-- **Projects** — los destacados, con tech, descripción corta y link en vivo.
-- **Skills** — agrupados, con nivel/%.
-- **Contact** — email **público** (nunca el personal), formulario o links.
+- **Hero** - nombre, headline, bio corto, links (GitHub/LinkedIn/email público).
+- **About** - bio medio/largo.
+- **Experience** - roles con highlights.
+- **Projects** - los destacados, con tech, descripción corta y link en vivo.
+- **Skills** - agrupados, con nivel/%.
+- **Contact** - email **público** (nunca el personal), formulario o links.
 
 ## Reglas
 
 - **El `.md` es la fuente.** Nunca editar el sitio sin reflejarlo en el source-of-truth (si no, vuelve el drift).
 - Email **público** en el sitio, jamás el personal/teléfono.
-- Respetar la arquitectura y el estilo del repo existente en modo `sync` — no reescribir todo.
+- Respetar la arquitectura y el estilo del repo existente en modo `sync` - no reescribir todo.
 - En `scaffold`, mantenerlo simple y rápido de hostear salvo que el usuario pida otra cosa.
 - No subir datos sensibles; el portfolio es público.
 

package/skills/review-dump/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: review-dump
+description: "Procesa el dump del dia en el vault: clasifica item por item con confirmacion, actualiza hub files, rutea tareas a su nota y crea el daily con la sintesis. Triggers: review dump, procesar el dump, cerrar el dia, revisar el inbox, clasificar lo que capture, crear el daily."
+argument-hint: "[today | YYYY-MM-DD]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+
+# Review Dump - Clasificar el día
+
+Convertís el dump crudo en estructura. Es la sesión donde el vault se ordena, y la única del ciclo diario que escribe en varios lugares: por eso va item por item, con confirmación, y nunca en batch silencioso.
+
+Día a procesar: `$ARGUMENTS` (default: hoy)
+
+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 - Preparación
+
+1. **Ubicar el vault** (`--vault`, env `OBSIDIAN_VAULT`, o directorio actual con `.obsidian/`) y leer su `CLAUDE.md`: de ahí salen la estructura real, el contrato de frontmatter y los plugins disponibles. Si no hay `CLAUDE.md`, ofrecer `/second-brain adopt` y parar.
+2. **Verificar git.** Si el vault es un repo y el árbol está sucio, avisarlo antes de escribir: esta corrida toca varias notas y git es el undo.
+3. **Leer el dump** `<inbox>/YYYY-MM-DD dump.md` (default `_inbox/`), aceptando también el nombre sin sufijo si el vault viene de antes. Si no existe, decirlo y ofrecer `/brain-dump`. Si ya existe el daily de ese día, avisar que se va a actualizar y no duplicar secciones.
+4. **Inventariar el vault una sola vez**, desde el índice cacheado y no con `Glob`:
+
+   ```bash
+   python .claude/skills/vault-recall/scripts/vault_index.py "<vault>" inventory --format text
+   ```
+
+   Devuelve hubs con sus alias, proyectos, areas, los dumps sin daily y las fechas del último weekly y monthly. Es lo que necesitás para proponer destinos reales, y su costo no crece con el vault: un `Glob` de cuatro carpetas sobre miles de notas mete un listado enorme en contexto en cada corrida. Si el vault usa otra estructura, pasar `--role nombre=ruta` con lo que diga el contrato. Sin el script, `Glob` de los roles `hubs`, `projects`, `areas` y `atomic`.
+
+## Fase 2 - Clasificación item por item
+
+Para cada línea del dump, proponer un destino y esperar confirmación. Una línea por propuesta, agrupando las obvias para no hacer 30 preguntas:
+
+| Lo que es | Destino |
+|---|---|
+| Tarea de un proyecto existente | La nota del proyecto en `<projects>` (default `01_Projects/`) |
+| Tarea del día sin proyecto | Se queda en el dump |
+| Idea que se sostiene sola | Nota atómica nueva en `<atomic>` (default `03_Resources/`), delegar a `/zettel` |
+| Mención de una entidad con hub existente | Entrada en `## Historial` de ese hub |
+| Mención de una entidad recurrente sin hub | Proponer hub nuevo (delegar a `/hub-note`) |
+| URL para leer después | Se queda en el dump, o `/vault-clip` si el usuario lo quiere ahora |
+| Ruido, duplicado, ya resuelto | Nada: se deja en el dump y se marca resuelto |
+
+**Taxonomía de la captura.** Antes de decidir destino, clasificá qué **tipo** de captura es. Adaptado del patrón de organización por tipo en vez de por tema: el tema crea silos (una nota de psicología de la atención y una de por qué el contenido corto rinde nunca se cruzan), el tipo crea colisiones, y las colisiones son de donde sale lo original.
+
+| Tipo | Qué es | Suele terminar en |
+|---|---|---|
+| observación | algo que noté, sin conclusión todavía | dump, o `atomic` si se sostiene sola |
+| reacción | mi respuesta honesta a algo que leí o escuché | dump, o `## Historial` del hub del tema |
+| patrón | el mismo principio apareciendo en dos dominios distintos | casi siempre `atomic`: es la materia prima del conocimiento |
+| pregunta | algo que genuinamente no sé | dump, y al weekly como hilo abierto |
+| número | un dato concreto, con su fuente | hub del tema, o `atomic` si el número prueba algo |
+
+**Afilado.** Cada item que se mueve del dump se reescribe en una línea que se entienda sola: si todavía necesita explicación, no está afilada. "las notas sin links no se encuentran" es flojo; "una nota sin link entrante es invisible desde el día que se escribe" se sostiene sin contexto. El afilado se muestra al usuario para que confirme, porque es su idea y sus palabras.
+
+Reglas de la clasificación:
+
+- **Proponé, no decidas.** Cada movimiento se confirma. Si el usuario dice que no, el item se queda en el dump: quedarse es un destino válido y no es un fracaso.
+- **Una entidad merece hub cuando aparece en tres dumps distintos**, no la primera vez. Antes de eso es una mención, no un tema.
+- **Una idea merece nota atómica cuando el usuario podría querer linkearla desde otra cosa.** Si solo tiene sentido dentro del día en que se escribió, se queda en el dump.
+- No inventes destinos: las carpetas y los hubs propuestos tienen que existir en el inventario, o crearse explícitamente.
+
+## Fase 3 - Tareas
+
+Aplicar la regla de arrastre sin excepción:
+
+1. Buscar tareas abiertas en los dumps de días anteriores (últimos 7 días alcanza).
+2. Las que sigan abiertas se marcan `- [-]` (canceladas) **en su día original**, con el motivo si el usuario lo dice. No se mueven.
+3. Si la tarea sigue vigente, se crea de nuevo: en la nota del proyecto si tiene uno, o en el dump de hoy.
+4. Si hay plugin `obsidian-tasks-plugin`, usar su sintaxis de fecha y prioridad; si no, checkbox plano. No mezclar.
+
+Verdict de esta fase: PASS cuando ninguna tarea quedó duplicada entre un día viejo y el nuevo.
+
+## Fase 4 - Escribir
+
+Con approval sobre lo recolectado, en este orden:
+
+1. Notas atómicas nuevas y hubs nuevos (para que existan antes de que algo los linkee).
+2. Actualización de hubs existentes: entrada en `## Historial`, y reescritura de `## Estado actual` solo si cambió de verdad.
+3. Tareas en las notas de proyecto.
+4. El daily en `<daily>/YYYY-MM-DD.md` (default `Reflect/Daily/`) desde `<templates>/Daily.md`: link al dump, síntesis de 3 a 5 líneas, links a las notas creadas, y el estado real de las tareas del día.
+5. El dump queda como está, salvo las marcas de tarea. **El dump no se borra ni se vacía nunca:** es el registro crudo de lo que pasó ese día.
+
+Los links van hacia arriba: el daily linkea al dump y a las notas creadas; ninguna nota atómica linkea de vuelta al daily.
+
+## Fase 5 - Cierre
+
+1. **Reescribir `hot.md`** en la raíz del vault (desde `Templates/hot.md` la primera vez): dónde está el usuario, las notas que cambiaron con un link cada una, los hilos abiertos y las tareas vivas. Techo de 40 líneas, sin secretos, sin transcripciones crudas, y ninguna afirmación sin su link. **Se reescribe completo, no se le agrega al final.** Es el archivo que hace que la próxima sesión abra sabiendo dónde estabas, y es descartable: si contradice a una nota, la nota gana.
+2. Reportar en una tabla qué se creó, qué se actualizó y qué quedó en el dump.
+3. La sección `## Reflexión` del daily queda vacía: la escribe el usuario. No la completes ni la sugieras.
+4. Si el vault es un repo git, recordar el commit.
+
+Review COMPLETE cuando existe el daily, `hot.md` refleja el estado de hoy, los hubs tocados quedaron consistentes y ninguna tarea quedó duplicada.
+
+## Reglas
+
+- Escribir los hechos, no interpretarlos: la síntesis dice qué pasó, no qué significa.
+- Idempotente: correr el review dos veces sobre el mismo día no duplica entradas de historial ni secciones del daily.
+- Nunca borrar contenido del dump.
+- Sin guiones largos en nada de lo que escribas.
+- Si el dump tiene más de 40 items, proponer procesar por bloques temáticos en vez de item por item, y decir por qué.
+
+## Handoff
+
+Con el daily listo, el siguiente paso depende del día: durante la semana volver a `/brain-dump`, y al cierre `/review-weekly` para extraer los temas de la semana. Si la corrida dejó varias entidades sin hub o varias ideas sin nota, `/hub-note` y `/zettel` son los pasos puntuales.

package/skills/review-monthly/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: review-monthly
+description: "Retrospectiva mensual del vault: lee los weeklies del mes, detecta patrones que no se ven en una semana, registra logros con evidencia y deja semillas para el mes siguiente. Triggers: review mensual, cerrar el mes, retrospectiva del mes, monthly review, patrones del mes."
+argument-hint: "[current | YYYY-MM]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash, Write, Edit
+---
+
+# Review Monthly - Cerrar el mes
+
+El nivel más alto del ciclo. El daily registra, el weekly detecta temas, el monthly detecta lo que ninguna semana sola muestra: qué avanzó de verdad, qué se repite sin moverse y qué merece atención el mes que viene.
+
+Mes a procesar: `$ARGUMENTS` (default: el mes en curso)
+
+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 - Leer el mes
+
+1. **Ubicar el vault** y leer su `CLAUDE.md`.
+2. **Leer los weeklies del mes (rol `weekly`).** Los weeklies son la fuente: no releas los dailies ni los dumps, ese trabajo ya está hecho y releerlo quema contexto sin agregar nada. Si faltan weeklies, listarlos y ofrecer `/review-weekly` para esas semanas antes de seguir.
+3. **Correr `/vault-audit`** para tener las métricas de salud del vault del mes (huérfanas, notas stale, semillas que no crecieron, notas `contested`, tareas viejas abiertas). El monthly es el momento natural del ciclo para mirarlas.
+4. **Presupuesto de lectura:** los weeklies del mes más el reporte del audit. Techo de 15 lecturas. Si faltan weeklies, se listan y se para: un monthly sobre dailies crudos cuesta diez veces más y sale peor.
+
+## Fase 2 - Extraer
+
+1. **Patrones:** lo que se repite a lo largo de varias semanas. Distinto de un tema semanal: un patrón es un tema que sobrevivió al mes.
+2. **Logros:** lo que efectivamente se cerró, cada uno con link a la nota que lo respalda. Sin evidencia linkeable no es un logro, es una impresión.
+3. **Lo que no se movió:** proyectos abiertos sin actividad en el mes, hilos que siguen abiertos desde la primera semana. Se nombran.
+4. **Semillas:** lo que apareció este mes y merece seguimiento, con el link a donde apareció.
+5. **Salud del vault:** las tres o cuatro métricas del audit que cambiaron respecto del mes anterior, si hay un monthly previo para comparar.
+6. **Contradicciones sin resolver:** las notas que el audit reporta como `contested`, cada una con el bloque `> [!warning] Contradicción sin resolver` que trae las dos posiciones y su fuente (mismo formato que usa `/review-weekly`). No las resuelvas: mostralas, con desde cuándo están abiertas. Que el vault te avise cuándo se contradice consigo mismo es una función, no un defecto. Si el usuario resuelve una en el momento, la resolución es una nota atómica nueva que linkea a las dos, y recién ahí se les saca el `contested`.
+
+## Fase 3 - Escribir
+
+Con approval sobre lo extraído, crear `<monthly>/YYYY-MM.md` (default `Reflect/Monthly/`) desde `<templates>/Monthly.md`, con links a los weeklies del mes. Si ya existe, actualizarlo sin duplicar secciones.
+
+Los links van hacia arriba: el monthly linkea a los weeklies y a las notas que respaldan los logros. No se edita ningún weekly desde acá.
+
+La sección `## Reflexión` queda vacía para el usuario.
+
+Review COMPLETE cuando existe el monthly con patrones, logros con evidencia y el estado de salud del vault.
+
+## Reglas
+
+- Un logro sin link no se escribe.
+- Lo que no avanzó se reporta con el mismo detalle que lo que avanzó.
+- Sin coaching: no proponés objetivos ni planes de mejora salvo que el usuario los pida.
+- Idempotente: correrlo dos veces sobre el mismo mes no duplica nada.
+- Sin guiones largos.
+
+## Handoff
+
+Con el monthly listo, si el audit reportó problemas el siguiente paso es `/vault-tidy` para aplicar los arreglos con approval. Si el mes dejó semillas que ya son ideas formadas, `/zettel`. Si no, se vuelve al ciclo diario con `/brain-dump`.

package/skills/review-weekly/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: review-weekly
+description: "Retrospectiva semanal del vault: lee los dumps y dailies de la semana, extrae temas recurrentes e hilos abiertos, cuenta tareas hechas y no hechas, y crea el weekly. Triggers: review semanal, cerrar la semana, retrospectiva de la semana, weekly review, que paso esta semana."
+argument-hint: "[current | YYYY-Www | YYYY-MM-DD]"
+category: "pkm"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+
+# Review Weekly - Cerrar la semana
+
+Subís un nivel de abstracción: el daily registra, el weekly detecta patrones. Lo que buscás son los temas que se repitieron y los hilos que quedaron abiertos, no un resumen de siete resúmenes.
+
+Semana a procesar: `$ARGUMENTS` (default: la semana en curso, lunes a domingo)
+
+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 - Leer la semana
+
+1. **Ubicar el vault** y leer su `CLAUDE.md`.
+2. **Resolver el rango**: si el argumento es una fecha, la semana ISO que la contiene; si es `YYYY-Www`, esa; si no hay argumento, la semana en curso.
+3. **Leer los dailies del rango (rol `daily`) y sus dumps (rol `inbox`).** Los dailies dan la síntesis, los dumps dan lo que no llegó a la síntesis. Faltan dailies casi siempre: anotá qué días quedaron sin procesar y ofrecé `/review-dump` para esos días antes de seguir, porque un weekly sobre dumps crudos es peor.
+4. **Presupuesto de lectura:** los 7 dailies del rango, sus dumps, y hasta 10 hubs de los que esos dailies linkean. Techo duro de 25 lecturas. Si el material no alcanza para sacar conclusiones, **decilo y pará** en vez de entregar un weekly a medias con cara de completo.
+
+## Fase 2 - Extraer
+
+1. **Temas:** de 3 a 5 asuntos que aparecen en dos días o más. Cada tema con los dailies donde aparece. Un tema que aparece un solo día no es un tema, es un evento.
+
+Una conexión califica solo si es de uno de estos cuatro tipos (rúbrica adaptada del patrón de sesiones de conexión):
+
+| Tipo | Qué buscar |
+|---|---|
+| **A** | El mismo principio en dos dominios distintos |
+| **B** | Dos notas que se contradicen y la contradicción es productiva |
+| **C** | Un patrón que solo aparece juntando tres notas o más, y todavía no tiene nombre |
+| **D** | Una pregunta de una nota que otra nota responde sin proponérselo |
+
+Para no depender solo de lo que recordás de la semana, pedile candidatos al índice: `vault_index.py "<vault>" related "<nota de la semana>"` devuelve las notas más cercanas por vocabulario compartido, y ahí suelen estar las del tipo A y C. El criterio de si califican sigue siendo tuyo: el script propone vecinos, no conexiones.
+
+**Si la conexión es obvia, no califica.** El test es: ¿el usuario la habría encontrado solo, eventualmente? Si sí, sobra. Este paso se gana el lugar encontrando lo que él se pierde. Mínimo 3, máximo 5: por encima de eso la lista deja de leerse.
+
+Las del tipo B se marcan: las dos notas involucradas van al weekly como contradicción, y si el usuario confirma que sigue sin resolverse, se les pone `status: contested` en el frontmatter con approval. La contradicción se preserva, no se resuelve sola.
+
+### El artefacto de una contradicción
+
+Cuando una conexión tipo B se confirma, el weekly lleva un bloque con **las dos posiciones enfrentadas y su fuente**, no una síntesis que las promedie:
+
+```markdown
+> [!warning] Contradicción sin resolver
+> **[[Nota A]]** dice: <la afirmación, textual o parafraseada fielmente>
+> **[[Nota B]]** dice: <la otra>
+> Sin resolver desde YYYY-MM-DD. Las dos quedan `status: contested`.
+```
+
+Se usa `[!warning]` con título propio y no `[!contradiction]`: ese tipo no existe en Obsidian y renderizaría como un `note` cualquiera sin avisar (ver `/obsidian-markdown`).
+
+Tres reglas del artefacto:
+
+- **No la resuelvas.** Si te parece obvio cuál de las dos gana, decilo como comentario aparte; la nota no elige.
+- **No borres ninguna de las dos.** Una contradicción resuelta borrando la mitad no se resolvió, se tapó.
+- **Cuando el usuario la resuelve**, se le saca el `contested` a las dos y la resolución va como nota atómica propia, linkeando a ambas. Eso es conocimiento nuevo: es el caso donde la contradicción produjo algo.
+2. **Hilos abiertos:** preguntas o decisiones pendientes, distintas de una tarea. "Definir si migramos" es un hilo; "mandar el mail" es una tarea.
+3. **Tareas:** conteo de hechas y de no hechas, con las no hechas nombradas una por una. No suavizar el número ni omitirlas.
+4. **Notas que crecieron:** hubs y notas atómicas que recibieron contenido en la semana.
+5. **Señales, si aparecen:** un tema que se repite tres semanas seguidas sin avanzar, o un proyecto sin una sola mención en toda la semana. Reportarlas como observación, sin diagnóstico ni consejo.
+
+## Fase 3 - Escribir
+
+Refrescar también `hot.md` con los hilos abiertos de la semana, respetando su techo de 40 líneas.
+
+Con approval sobre lo extraído, crear `<weekly>/YYYY-Www.md` (default `Reflect/Weekly/`) desde `<templates>/Weekly.md`, con links a los dailies de la semana. Si el weekly ya existe, actualizarlo sin duplicar secciones.
+
+Los links van hacia arriba: el weekly linkea a los dailies. Ningún daily se edita para linkear al weekly.
+
+La sección `## Reflexión` queda vacía para el usuario.
+
+Review COMPLETE cuando existe el weekly con temas, hilos y el conteo real de tareas.
+
+## Reglas
+
+- Sin interpretación: reportás lo que pasó y lo que se repitió, no qué significa ni qué debería hacer el usuario.
+- Las tareas no hechas se nombran. Un weekly que las esconde no sirve para nada.
+- Idempotente: correrlo dos veces sobre la misma semana no duplica nada.
+- Solo el rango de la semana: nunca reescribir dailies ni dumps pasados desde acá.
+- Sin guiones largos.
+
+## Handoff
+
+Con el weekly listo, el siguiente paso es seguir con `/brain-dump` la semana que viene, y al cierre del mes `/review-monthly`, que lee los weeklies y no los dailies. Si el weekly dejó al descubierto un tema que ya merece nota propia, `/zettel` o `/hub-note`.

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
+          }
+        ]
+      }
+    ]
+  }
+}