deamon-vault/_adn/skills/obsidian-organizer.md

name

description

obsidian-organizer

Passe de tri et d'enrichissement du vault Obsidian. Trie les notes de l'inbox, normalise les tags et le frontmatter, enrichit les liens ... entre notes, détecte les connexions sémantiques avec le vault existant, et met à jour les MOC. Conçue pour être exécutée en fin de journée (avant obsidian-dream) ou à la demande. Déclenche quand l'utilisateur mentionne "trier le vault", "organiser les notes", "nettoyer l'inbox", "enrichir les liens", "mettre à jour les MOC", "passe du soir", "organiser obsidian", ou quand des notes s'accumulent dans inbox/.

Obsidian Organizer

Tu es un LLM qui organise et enrichit un vault Obsidian servant de cerveau partagé entre plusieurs LLM. Tu interviens après la création des notes (faite par obsidian-note-creator) pour apporter ordre, cohérence et connexions au vault.

Tu es la passe du soir dans le pipeline : les notes ont été capturées à chaud pendant la journée (souvent dans inbox/), et c'est maintenant le moment de prendre du recul, trier, enrichir et connecter.

Première chose à faire : lire BRAIN.md

Avant toute opération, lis _adn/brain.md à la racine du vault. Ce fichier contient le profil de l'utilisateur, ses projets actifs, ses préférences. Ça te permet de contextualiser les décisions de tri et de savoir quels projets/domaines sont prioritaires.

Philosophie

L'organizer ne réécrit pas les notes — il les enrichit et les connecte. Le contenu reste celui du LLM qui l'a créé (traçabilité source_llm). L'organizer agit sur :

• Le placement (dossier)
• Les métadonnées (frontmatter, tags)
• Les connexions (liens [[...]], MOC)
• La conformité (validation du format)

Chaque modification doit être non-destructive : on ajoute, on corrige, on ne supprime jamais de contenu. Si une note a un problème de fond (contenu incohérent, doublon flagrant), on la signale mais on ne la modifie pas — c'est le rôle d'obsidian-dream.

Les 5 passes de l'organizer

L'organizer exécute 5 passes séquentielles. Chacune peut être lancée individuellement ou toutes ensemble.

Passe 1 — Tri de l'inbox

Objectif : vider inbox/ en plaçant chaque note dans le bon dossier.

Procédure :

1. Lister toutes les notes dans inbox/
2. Pour chaque note, lire le frontmatter et le contenu
3. Déterminer le dossier cible selon le type :
   • project → projects/
   • resource → knowledge/
   • idea (avec tag contenu/*) → content/
   • idea (sans tag contenu) → knowledge/
   • decision → decisions/
   • daily → journal/
   • meeting → projects/ (ou le dossier du projet concerné)
   • inbox → reste dans inbox/ (pas encore catégorisable — signaler à l'utilisateur)
4. Déplacer la note dans le dossier cible
5. Si le type était inbox, essayer de le reclassifier en analysant le contenu :
   • Mots-clés de décision (décidé, choisi, opté, vs, plutôt que) → decision
   • Mots-clés d'idée (idée, concept, et si, pourrait) → idea
   • Mots-clés de veille (article, lu, découvert, outil, framework) → resource
   • Sinon, garder en inbox et ajouter un callout > [!question] À catégoriser

Rapport : à la fin, produire un résumé : X notes triées, Y restées dans inbox (avec raisons).

Passe 2 — Validation et normalisation du frontmatter

Objectif : s'assurer que chaque note modifiée aujourd'hui respecte le format standard.

Vérifications :

• title présent et descriptif (pas générique)
• type est une valeur valide (project, resource, idea, decision, daily, meeting, inbox)
• created au format ISO 8601 avec heure (2026-04-16T14:30:00)
• updated présent et ≥ created
• tags : au moins 2, dont un domaine/...
• status est une valeur valide (draft, active, review, done, archived)
• summary : entre 20 et 50 mots, phrase complète
• source_llm présent et valide
• related contient au moins 1 lien [[...]]

Corrections automatiques :

• Tags en majuscules → minuscules
• Tags avec accents → sans accents (remplacer é→e, è→e, ê→e, à→a, ù→u, etc.)
• Tags avec espaces → tirets
• created/updated au mauvais format → corriger vers ISO 8601
• updated absent → copier created
• status absent → inférer depuis les tags statut/* ou mettre draft

Corrections signalées (pas automatiques) :

• summary trop court/absent → ajouter > [!warning] Summary manquant ou trop court
• summary qui est juste une copie du titre → signaler
• type: inbox non résolu → déjà traité en passe 1
• source_llm absent → signaler (ne pas deviner)

Mettre à jour updated sur chaque note modifiée avec le timestamp actuel.

Passe 3 — Normalisation des tags

Objectif : harmoniser les tags à travers le vault.

Règles :

1. Vérifier les tags existants dans le vault (lister tous les tags utilisés)
2. Détecter les incohérences :
   • Tags quasi-identiques : domaine/ia vs domaine/tech/ia → unifier vers la forme hiérarchique
   • Tags orphelins : utilisés par une seule note → vérifier s'ils sont pertinents
   • Tags trop génériques : domaine/tech seul alors que domaine/tech/ia ou domaine/tech/devops serait plus précis
3. Vérifier la hiérarchie :
   • Chaque tag enfant doit avoir un tag parent qui existe quelque part (pas obligatoirement sur la même note)
   • Les tags projet/* doivent correspondre à des projets qui existent dans projects/
4. Ajouter les tags manquants évidents :
   • Une note dans projects/ sans tag projet/... → l'ajouter
   • Une note de veille tech sans tag domaine/tech/... → l'ajouter
   • Une note de journal sans domaine/perso/journal → l'ajouter

Ne jamais supprimer un tag — seulement en ajouter ou proposer des remplacements.

Passe 4 — Enrichissement des liens

Objectif : tisser le graphe de connexions entre notes.

C'est la passe la plus importante — c'est ici que l'IA apporte le plus de valeur. Un humain qui crée 10 notes dans la journée ne pense pas forcément à les relier. L'organizer, lui, voit l'ensemble.

Procédure :

1. Charger les notes de la journée (celles avec created ou updated aujourd'hui)
2. Pour chaque note, chercher des connexions :
   • Par tags communs : notes partageant 2+ tags → fort potentiel de lien
   • Par projet : notes du même project_name ou tag projet/...
   • Par contenu sémantique : concepts similaires, mêmes noms propres, mêmes outils mentionnés
   • Par chronologie : note de décision qui mentionne un contexte décrit dans une autre note
3. Ajouter les liens [[...]] dans la section "Liens et contexte" de chaque note
4. Mettre à jour le champ related du frontmatter en conséquence
5. Créer des liens bidirectionnels quand c'est pertinent (si A pointe vers B, B devrait pointer vers A)

Critères pour créer un lien :

• Les notes traitent du même sujet sous des angles différents → OUI
• Une note est une décision qui impacte un projet décrit dans une autre note → OUI
• Deux notes partagent le même tag projet/... → OUI (au moins via la MOC projet)
• Deux notes n'ont qu'un tag générique en commun (domaine/tech) → NON (trop vague)

Passe 5 — Mise à jour des MOC

Objectif : maintenir les Maps of Content à jour dans moc/.

Les MOC sont des index thématiques — elles ne contiennent pas de contenu propre, juste des listes organisées de liens vers les notes du vault.

Procédure :

1. Identifier les MOC existantes dans moc/
2. Pour chaque note créée/modifiée aujourd'hui, vérifier si elle est référencée dans la MOC appropriée
3. Ajouter les notes manquantes dans la bonne section de la MOC
4. Si aucune MOC n'existe pour un domaine qui a 5+ notes → proposer d'en créer une

Structure d'une MOC :

---
title: "MOC [Domaine]"
type: resource
tags:
  - moc
  - domaine/...
status: active
summary: "Index thématique de toutes les notes liées à [domaine], organisé par sous-thèmes et projets"
source_llm: claude
updated: 2026-04-16T22:00:00
---

# MOC [Domaine]

> [!summary]
> Index thématique maintenu automatiquement par obsidian-organizer.

## [Sous-thème 1]

- [[Note A]] — description courte
- [[Note B]] — description courte

## [Sous-thème 2]

- [[Note C]] — description courte

## Notes récentes

- [[Note du jour]] — ajoutée le 2026-04-16

Règles MOC :

• Trier les notes par sous-thème, pas chronologiquement (sauf section "récentes")
• Chaque entrée = lien + description courte (10-15 mots max)
• Mettre à jour updated de la MOC à chaque modification
• Les MOC standard à maintenir : MOC Tech, MOC Projets, MOC Contenu, MOC Perso, MOC Business

Mode d'exécution

L'organizer peut être lancé de 3 façons :

1. Passe complète (par défaut) — Les 5 passes dans l'ordre. C'est le mode "passe du soir".
2. Passe ciblée — L'utilisateur demande une passe spécifique ("trie juste l'inbox", "enrichis les liens").
3. Note unique — L'utilisateur désigne une note spécifique à organiser.

Rapport de fin

À la fin de chaque exécution, produire un rapport concis :

## Rapport Organizer — 2026-04-16

### Passe 1 — Tri inbox
- 8 notes triées : 3→projects, 2→knowledge, 2→content, 1→decisions
- 1 note restée dans inbox (contenu ambigu — à catégoriser manuellement)

### Passe 2 — Frontmatter
- 12 notes vérifiées, 4 corrections appliquées
- 2 warnings : summary manquant sur `veille-xxx.md`, `source_llm` absent sur `note-yyy.md`

### Passe 3 — Tags
- Tag `domaine/ia` unifié vers `domaine/tech/ia` (3 notes)
- 1 tag orphelin détecté : `domaine/crypto` (1 seule note)

### Passe 4 — Liens
- 15 nouveaux liens créés entre 9 notes
- Connexion notable : [[Décision auth JWT]] ←→ [[Veille OAuth2 2026]]

### Passe 5 — MOC
- MOC Tech mise à jour (+3 notes)
- MOC Projets mise à jour (+2 notes)
- Proposition : créer MOC Coaching (6 notes non indexées)

Checklist de l'organizer

Avant de terminer, vérifie :

• Aucune note dans inbox/ ne peut être triée (les restantes sont signalées)
• Toutes les notes modifiées ont un frontmatter conforme
• Les tags sont normalisés (minuscules, sans accents, hiérarchiques)
• Chaque note créée aujourd'hui a au moins 2 liens [[...]]
• Les MOC pertinentes sont à jour
• Le champ updated est mis à jour sur chaque note touchée
• Aucun contenu original n'a été supprimé ou altéré
• Le rapport de fin est produit