LLM Wiki Distiller

¿Qué hace LLM Wiki Distiller?

Idea central

Mantener una base de conocimiento personal orientada al uso por parte de modelos de lenguaje grandes: registrar qué ha aprendido el usuario, qué valora, qué nota, qué ha guardado, qué siempre olvida, y qué desea que los modelos futuros recuerden. No repitas conocimiento enciclopédico general; concéntrate en la perspectiva propia del usuario, las rutas de origen, la información nueva posterior a la fecha de corte de entrenamiento y el contexto personal reutilizable.

La raíz de la base se compone fijamente de cuatro directorios + tres archivos raíz (index.md / log.md / pending.md):

1. raw/: Material original, adjuntos y bandeja de entrada (inbox) pendiente.
2. wiki/: Entradas destiladas mantenidas por el LLM.
3. _staging/: Propuestas provisionales para procesamiento paralelo en lote (directorio permanente, contenido transitorio: se elimina tras ser consumido por integrate).
4. review/: Informes de revisión (review/YYYY-MM/ archivados por mes; el último informe sirve también como cursor de revisión).

Cualquier creación, modificación, eliminación, archivado o revisión sustancial debe actualizar sincrónicamente index.md y log.md.

Mapa de recursos

Este archivo solo se encarga del enrutamiento. Tras determinar el modo, lee inmediatamente el modo correspondiente; el modo te indicará qué referencias/esquemas leer a continuación.

• modes/quick.md: Adiciones, modificaciones, archivados y eliminaciones rápidos sin pasar por la bandeja de entrada.
• modes/distill.md: Procesa material de raw/inbox/ u otros materiales raw y los destila formalmente.
• modes/review.md: Revisión, comprobación de salud y propuestas de fusión; cada ronda produce un informe fechado.
• modes/search.md: Consultas de solo lectura y resúmenes, sin escritura.
• modes/integrate.md: Cuando se orquesta en paralelo, el orquestador unifica varias propuestas de subagentes de solo captura en la base de datos (escritor único, serial).
• references/raw.md: Directorio raw, clasificación de fuentes, adjuntos y manejo de material duplicado.
• references/wiki.md: Criterios para tipos de página wiki, límites y reglas de escritura.
• schemas/common.md: Campos YAML comunes, vocabulario controlado, fechas y estados.
• schemas/raw.md: Punteros de Markdown raw, metadatos de fuente y reglas de referencia a adjuntos.
• schemas/wiki.md: Frontmatter y estructura del cuerpo para cada tipo de página wiki.
• schemas/root.md: Formato de index.md, log.md y pending.md.
• schemas/report.md: Ubicación del informe de revisión, frontmatter y estructura del cuerpo (el último informe sirve como cursor de revisión).
• schemas/proposal.md: Formato de propuesta provisional para el flujo de solo captura → integración durante la orquestación en paralelo.

No leas todos los recursos de una vez. Sigue los pasos del modo seleccionado de manera incremental.

Paso 0: Verificación del directorio raíz de la base de conocimiento

Antes de usar cualquier modo, confirma que el directorio de trabajo actual sea el directorio raíz de la base de conocimiento. Realiza solo una comprobación idempotente ligera, sin leer otros esquemas/referencias.

Trata el directorio actual como una base de conocimiento existente; debe cumplir al menos 2 tipos de señales:

• Existe raw/, y contiene inbox/, attachment/, dropzone/ u otras clasificaciones raw.
• Existe wiki/, y contiene concept/, entity/, summary/, scrap/ u otras clasificaciones wiki.
• Existen al menos 2 de los archivos raíz index.md, log.md, pending.md.

Acción:

• Si cumple 2 o más señales: continúa a la puerta de modo.
• Si cumple 0 señales y el directorio está vacío o casi vacío: pregunta al usuario si desea inicializar una base de conocimiento en el directorio actual, o proporciona una ruta a una base existente.
• Si cumple 0-1 señales y el directorio actual es claramente otro proyecto: detente, solicita al usuario la ruta de la base de conocimiento; no crees raw/, wiki/ en el proyecto actual.
• Si el usuario proporciona explícitamente una ruta de base de conocimiento en la solicitud, cambia a esa ruta y vuelve a realizar esta comprobación.

Puerta de modo

Selecciona entre cuatro modos según la semántica del usuario, sin requerir que el usuario nombre el modo:

1. El usuario quiere revisar/mantener la base existente, por ejemplo "revisa", "comprueba contradicciones", "ejecuta una comprobación de salud" → Lee modes/review.md.
2. El usuario solo quiere consultar/preguntar/resumir contenido existente, sin necesidad de añadir o modificar → Lee modes/search.md.
3. El usuario quiere añadir, modificar, archivar o eliminar, pero no necesita procesar material raw/inbox → Lee modes/quick.md.
4. El usuario quiere procesar raw/inbox/, recortes web, textos largos, chats, redes sociales, PDFs, transcripciones de video, proyectos de GitHub u otros materiales raw → Lee modes/distill.md.

Si el modo no está claro, prioriza determinar si el usuario solicita escritura; si la escritura implica fuentes no procesadas, usa destilación; si es solo consulta, usa búsqueda; si es mantenimiento de la base, usa revisión.

Aclaración sobre orquestación en paralelo: El modo de destilación tiene una variante de "solo captura" (cada subagente reclama una sola entrada, escribe solo su propio resumen + raw + propuesta _staging/<id>.md, sin tocar páginas compartidas), que se combina con el modo integrate (el orquestador unifica varias propuestas en la base). Las restricciones se detallan en la sección "Modo de ejecución" de modes/distill.md; cuándo paralelizar y cómo asignar subagentes lo decide el archivo CLAUDE.md del proyecto que llama, no este skill.

Reglas estrictas compartidas

• Trata el wiki como "memoria compilada", no como un repositorio de texto original. Conserva las rutas de origen raw, no copies el texto original completo en el wiki.
• original_url en YAML solo debe contener URLs externas principales, para abrir rápidamente páginas web, videos, publicaciones, artículos, páginas de proyectos, etc.; solo se permiten http:// o https://. Los archivos .md locales, rutas raw/..., wiki/summary/..., rutas de adjuntos, rutas de archivo absolutas/relativas, enlaces internos de Obsidian y enlaces a documentos locales en conversaciones nunca deben escribirse en original_url; si no hay URL externa, déjalo como arreglo vacío []. Las rutas raw, páginas de resumen y relaciones de evidencia internas se escriben en el cuerpo bajo ## Fuentes o related. Las búsquedas complementarias, material de contexto y lecturas adicionales van en ## Fuentes al final del cuerpo, no en el frontmatter. No uses el campo sources en el YAML del wiki.
• El conocimiento anterior a 2025-01-01 se escribe de forma ligera por defecto, a menos que sea importante para el usuario, poco común, o constituya la base del pensamiento del usuario. El conocimiento posterior a 2025-01-01 puede recibir más atención, ya que puede cubrir lagunas posteriores al corte de entrenamiento del modelo, pero la prioridad sigue siendo "útil" en lugar de "completo".
• Usa fechas absolutas. No escribas solo "ayer", "hoy" o "recientemente" en hechos persistentes, a menos que también se especifique la fecha absoluta.
• Distingue entre hechos, inferencias, preferencias y señales débiles. Las señales débiles no se escriben directamente como hechos estables.
• Cuando una fuente nueva entre en conflicto con una página existente, conserva ambas versiones, las fuentes y las fechas, marca el conflicto y no sobrescribas en silencio.
• Antes de escribir, busca páginas duplicadas, títulos similares, alias, URLs de origen y frases clave.
• Por defecto, no elimines físicamente el conocimiento; archiva, marca como obsoleto o reemplazado conservando el historial. Confirma antes de cualquier eliminación real.
• Para conclusiones sensibles, de alto impacto, médicas/legales/financieras o que definan la identidad, si la evidencia es ambigua, pregunta al usuario antes de escribir.
• Distingue entre "trabajo de juicio" y "operaciones mecánicas": el trabajo de juicio (decisiones de destilación, fusiones, evaluar si un contenido es importante o debe eliminarse durante la revisión) debe realizarlo directamente el agente comprendiendo el significado, sin delegarlo a scripts que adivinen — ese es el valor de este skill, los scripts carecen de criterio. Las operaciones mecánicas (filtrado según reglas claras, conteo, renombrado, conversión de formato, e infraestructura como búsqueda local, índices o bases vectoriales cuando la base crezca) se deben realizar preferentemente con herramientas de línea de comandos o scripts.
• Al ejecutar operaciones mecánicas, prioriza métodos que no requieran leer el contenido completo del archivo en el contexto del agente (grep/sed/awk/scripts de una sola ejecución, ejecución ciega), y verifica los resultados con conteos y diff (wc -l, grep -c, git diff --stat), en lugar de leer el archivo completo o imprimirlo para comprobar — ahorra tokens y el resultado es igual de fiable. Solo lee antes de actuar si la operación requiere juicio (por ejemplo, decidir si eliminar cierto contenido durante una revisión).
• No incluyas archivos de orquestación de agentes. Los archivos AGENTS.md, CLAUDE.md o estrategias de subagentes de diferentes plataformas los mantiene el proyecto que los utiliza.