--- name: obsidian-organizer description: > 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 :** ```markdown --- 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 : ```markdown ## 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