claude-code-arcane 2.0.0 → 2.1.0

package/skills/vault-tidy/SKILL.md

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

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

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

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

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

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

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

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

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

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

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

package/skills/zettel/SKILL.md

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