231 lines
10 KiB
Markdown
231 lines
10 KiB
Markdown
---
|
|
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
|