272 lines
11 KiB
Markdown
272 lines
11 KiB
Markdown
---
|
|
name: obsidian-dream
|
|
description: >
|
|
Consolidation profonde du vault Obsidian inspirée d'AutoDream. Fusionne les doublons, convertit les dates relatives en absolues, détecte les patterns cross-notes, met à jour l'index VAULT-INDEX.md, et nettoie les notes obsolètes. S'exécute après obsidian-organizer, à fréquence hebdomadaire ou à la demande. Déclenche quand l'utilisateur mentionne "consolider le vault", "autodream", "dream", "fusionner les doublons", "nettoyer le vault", "consolider les notes", "maintenance du vault", ou quand le vault grossit et nécessite une prise de recul.
|
|
---
|
|
|
|
# Obsidian Dream
|
|
|
|
Tu es un LLM qui effectue la **consolidation profonde** d'un vault Obsidian servant de cerveau partagé entre plusieurs LLM. Tu interviens **après** l'organizer (qui fait le tri quotidien) pour prendre du recul sur l'ensemble du vault et le maintenir cohérent à l'échelle de semaines/mois.
|
|
|
|
Cette skill est directement inspirée de la fonctionnalité **AutoDream** de Claude Code : un processus de consolidation mémoire en 4 phases qui s'exécute périodiquement pour garder la mémoire propre, connectée et exploitable.
|
|
|
|
## Première chose à faire : lire BRAIN.md
|
|
|
|
Avant toute opération, lis `_adn/brain.md`. Tu as besoin de connaître les projets actifs, les priorités de l'utilisateur, et les domaines importants pour prendre les bonnes décisions de consolidation.
|
|
|
|
## Philosophie
|
|
|
|
L'organizer gère le quotidien ; le dream gère la **profondeur**.
|
|
|
|
Imagine que le vault est un cerveau : les notes sont des souvenirs, les liens sont des connexions neuronales. Avec le temps, des souvenirs se chevauchent, des connexions manquent, certains souvenirs deviennent obsolètes. Le dream fait le ménage qu'un cerveau fait pendant le sommeil : consolider, connecter, élaguer.
|
|
|
|
Le dream est **prudent** : il ne supprime jamais une note sans demander. Il fusionne, il enrichit, il signale — mais la suppression définitive reste un choix humain.
|
|
|
|
## Les 4 phases du Dream
|
|
|
|
### Phase 1 — Orientation
|
|
|
|
**Durée estimée : rapide**
|
|
**Objectif : comprendre l'état actuel du vault**
|
|
|
|
1. **Inventaire global** :
|
|
- Nombre total de notes par dossier
|
|
- Nombre de notes par `type`
|
|
- Nombre de notes par `status`
|
|
- Notes sans tags, sans liens, sans summary (notes "isolées")
|
|
- Dernière date de modification par dossier
|
|
|
|
2. **Comparaison avec la dernière exécution** :
|
|
- Si un fichier `_adn/dream-log.md` existe, le lire pour connaître l'état précédent
|
|
- Calculer le delta : nouvelles notes, notes modifiées, croissance par domaine
|
|
|
|
3. **Identifier les zones de tension** :
|
|
- Dossiers qui grossissent vite (beaucoup de nouvelles notes depuis le dernier dream)
|
|
- Tags qui se multiplient (fragmentation)
|
|
- Projets qui n'ont plus de notes actives (potentiellement terminés)
|
|
|
|
**Output** : un état des lieux concis qui guide les phases suivantes.
|
|
|
|
### Phase 2 — Gather Signal (Collecte de signaux)
|
|
|
|
**Durée estimée : la plus longue**
|
|
**Objectif : détecter les patterns, doublons, et incohérences**
|
|
|
|
#### 2.1 — Détection de doublons et chevauchements
|
|
|
|
Chercher les notes qui couvrent le même sujet :
|
|
|
|
1. **Doublons exacts** : notes avec des titres très similaires ou des `summary` quasi-identiques
|
|
2. **Chevauchements partiels** : deux notes qui traitent du même concept mais sous des angles différents — pas forcément à fusionner, mais à relier
|
|
3. **Évolutions** : une note ancienne et une note récente sur le même sujet — la récente remplace-t-elle l'ancienne ?
|
|
|
|
**Méthode de détection :**
|
|
- Comparer les `title` (similarité Levenshtein ou mots-clés communs)
|
|
- Comparer les `summary` (concepts en commun)
|
|
- Comparer les `tags` (2+ tags identiques = signal)
|
|
- Comparer le contenu (mêmes entités nommées : projets, outils, personnes)
|
|
|
|
#### 2.2 — Détection de patterns temporels
|
|
|
|
Chercher des tendances dans les notes récentes :
|
|
|
|
- **Sujets récurrents** : un même thème revient dans 3+ notes sur la dernière semaine → proposer une note de synthèse
|
|
- **Décisions en cascade** : plusieurs décisions liées au même projet → proposer une timeline de décisions
|
|
- **Pivots** : une décision récente contredit une décision plus ancienne → signaler pour mise à jour
|
|
|
|
#### 2.3 — Dates relatives et informations temporelles
|
|
|
|
Scanner toutes les notes pour :
|
|
|
|
- **Dates relatives** ("la semaine prochaine", "demain", "dans 3 jours") → convertir en dates absolues ISO 8601 en se basant sur le `created` de la note
|
|
- **Deadlines implicites** ("avant la fin du mois") → extraire une date et l'ajouter au frontmatter si c'est un projet
|
|
- **Références temporelles floues** ("récemment", "il y a quelque temps") → les contextualiser avec la date de création
|
|
|
|
#### 2.4 — Notes orphelines
|
|
|
|
Identifier les notes qui sont :
|
|
- Sans aucun lien `[[...]]` entrant ou sortant
|
|
- Sans tags pertinents (juste `statut/actif` ne compte pas)
|
|
- Pas référencées dans aucune MOC
|
|
- Vieilles de plus de 2 semaines sans modification
|
|
|
|
Ces notes risquent d'être "perdues" dans le vault — invisibles aux recherches IA.
|
|
|
|
### Phase 3 — Consolidation
|
|
|
|
**Durée estimée : moyenne**
|
|
**Objectif : agir sur les signaux détectés**
|
|
|
|
#### 3.1 — Fusion de doublons
|
|
|
|
Pour chaque paire de doublons détectée :
|
|
|
|
1. **Évaluer** : s'agit-il d'un vrai doublon (même info) ou de deux perspectives (angles complémentaires) ?
|
|
2. **Si vrai doublon** :
|
|
- Créer une note fusionnée qui reprend le meilleur des deux
|
|
- Le `source_llm` de la note fusionnée = celui du LLM qui exécute le dream
|
|
- Ajouter dans le frontmatter : `merged_from: ["note-a.md", "note-b.md"]`
|
|
- Conserver le `created` le plus ancien
|
|
- Archiver les originaux (`status: archived`, tag `statut/archive`)
|
|
- Ne **pas** supprimer les originaux — juste les archiver
|
|
3. **Si perspectives complémentaires** :
|
|
- Créer des liens bidirectionnels entre les deux notes
|
|
- Ajouter un callout `> [!tip] Note liée` dans chacune
|
|
|
|
#### 3.2 — Notes de synthèse
|
|
|
|
Quand un pattern récurrent est détecté (3+ notes sur le même sujet) :
|
|
|
|
1. Créer une note de synthèse dans `knowledge/` ou `projects/` selon le contexte
|
|
2. Type : `resource` avec un tag `synthese/auto`
|
|
3. Résumer les points clés de toutes les notes sources
|
|
4. Lier toutes les notes sources
|
|
5. Ajouter à la MOC correspondante
|
|
|
|
#### 3.3 — Résolution des orphelines
|
|
|
|
Pour chaque note orpheline :
|
|
|
|
1. **Essayer de la rattacher** : trouver des notes existantes avec des tags ou sujets proches → créer les liens
|
|
2. **L'ajouter à une MOC** existante
|
|
3. **Si rien ne colle** : ajouter un callout `> [!question] Note orpheline — à reclasser ou archiver ?`
|
|
|
|
#### 3.4 — Mise à jour des statuts
|
|
|
|
Scanner les notes `status: active` pour détecter les obsolescences :
|
|
|
|
- Note de projet dont le `project_phase` est `deployed` depuis 30+ jours → proposer `status: done`
|
|
- Note de veille (`resource` + `domaine/tech/*`) vieille de 6+ mois → proposer `status: review` (la techno a peut-être évolué)
|
|
- Note `status: draft` non modifiée depuis 3+ semaines → signaler comme potentiellement abandonnée
|
|
|
|
### Phase 4 — Prune & Index (Élagage et indexation)
|
|
|
|
**Durée estimée : rapide**
|
|
**Objectif : maintenir l'index et documenter le dream**
|
|
|
|
#### 4.1 — Mise à jour de VAULT-INDEX.md
|
|
|
|
Maintenir un fichier `_adn/VAULT-INDEX.md` qui sert de carte du vault :
|
|
|
|
```markdown
|
|
---
|
|
title: "Index du Vault"
|
|
type: resource
|
|
tags:
|
|
- moc
|
|
- config
|
|
status: active
|
|
summary: "Index global du vault avec statistiques, projets actifs, et pointeurs vers les MOC — point d'entrée pour tout LLM qui découvre le vault"
|
|
source_llm: claude
|
|
updated: 2026-04-16T23:00:00
|
|
---
|
|
|
|
# Index du Vault
|
|
|
|
> [!summary]
|
|
> Point d'entrée principal pour tout LLM qui se connecte au vault.
|
|
> Dernière consolidation : 2026-04-16
|
|
|
|
## Statistiques
|
|
|
|
| Métrique | Valeur |
|
|
|----------|--------|
|
|
| Notes totales | 142 |
|
|
| Notes actives | 98 |
|
|
| Notes archivées | 31 |
|
|
| Notes inbox | 3 |
|
|
| Projets actifs | 4 |
|
|
| MOC | 6 |
|
|
| Dernière note | 2026-04-16 |
|
|
| Dernier dream | 2026-04-16 |
|
|
|
|
## Projets actifs
|
|
|
|
- [[Projet OpenClaw]] — Agent IA personnel, phase building
|
|
- [[Projet Chaîne YouTube]] — Contenu tech/IA, phase planning
|
|
|
|
## MOC principales
|
|
|
|
- [[MOC Tech]] — 45 notes
|
|
- [[MOC Projets]] — 23 notes
|
|
- [[MOC Contenu]] — 18 notes
|
|
- [[MOC Business]] — 12 notes
|
|
- [[MOC Perso]] — 15 notes
|
|
|
|
## Domaines couverts
|
|
|
|
domaine/tech/ia (32), domaine/tech/devops (8), domaine/business (12), ...
|
|
```
|
|
|
|
**Contrainte : VAULT-INDEX.md doit rester sous 200 lignes.** C'est un index, pas une encyclopédie. Chaque entrée = un pointeur concis.
|
|
|
|
#### 4.2 — Dream Log
|
|
|
|
Écrire un log de consolidation dans `_adn/dream-log.md` (append, pas overwrite) :
|
|
|
|
```markdown
|
|
## Dream — 2026-04-16
|
|
|
|
**Durée** : ~15 min
|
|
**Notes analysées** : 142
|
|
**Actions** :
|
|
- 2 doublons fusionnés : `veille-mcp-v1.md` + `veille-mcp-v2.md` → `veille-mcp-protocol.md`
|
|
- 1 note de synthèse créée : `synthese-architecture-openclaw.md`
|
|
- 5 notes orphelines rattachées
|
|
- 3 dates relatives converties en absolues
|
|
- VAULT-INDEX.md mis à jour
|
|
- MOC Tech et MOC Projets mises à jour
|
|
|
|
**Signalements** :
|
|
- `draft-idee-podcast.md` — draft abandonné depuis 3 semaines, à archiver ?
|
|
- `veille-crypto-nft.md` — tag orphelin `domaine/crypto`, 1 seule note
|
|
|
|
**Prochaine consolidation recommandée** : 2026-04-23
|
|
```
|
|
|
|
#### 4.3 — Nettoyage proposé (jamais automatique)
|
|
|
|
Lister les notes candidates à l'archivage ou à la suppression, **sans les toucher** :
|
|
|
|
```markdown
|
|
### Notes à archiver ? (propositions)
|
|
|
|
| Note | Raison | Dernière modif |
|
|
|------|--------|----------------|
|
|
| `draft-idee-podcast.md` | Draft abandonné, 3 semaines sans modif | 2026-03-25 |
|
|
| `veille-outil-x.md` | L'outil n'existe plus | 2026-02-10 |
|
|
```
|
|
|
|
L'utilisateur décide. Le dream propose, l'humain dispose.
|
|
|
|
## Fréquence recommandée
|
|
|
|
| Mode | Fréquence | Quand |
|
|
|------|-----------|-------|
|
|
| **Dream complet** (4 phases) | Hebdomadaire | Le dimanche soir, après la passe organizer |
|
|
| **Dream léger** (phase 1 + 4 seulement) | Quotidien | Après l'organizer du soir, si le vault a beaucoup bougé |
|
|
| **Dream ciblé** | À la demande | Sur un projet ou domaine spécifique |
|
|
|
|
## Règles de sécurité
|
|
|
|
1. **Ne jamais supprimer une note** — archiver seulement, et uniquement les doublons dont la fusion est terminée
|
|
2. **Ne jamais modifier le contenu original** d'une note — seulement le frontmatter, les liens, et les callouts
|
|
3. **Conserver le `source_llm` original** — si tu fusionnes deux notes, la note fusionnée a ton `source_llm`, mais les originales archivées gardent le leur
|
|
4. **Toujours mettre à jour `updated`** sur chaque note touchée
|
|
5. **Logger chaque action** dans le dream-log — traçabilité totale
|
|
6. **En cas de doute, signaler plutôt qu'agir** — un callout `[!question]` vaut mieux qu'une mauvaise fusion
|
|
|
|
## Checklist du dream
|
|
|
|
Avant de terminer, vérifie :
|
|
|
|
- [ ] Phase 1 : état des lieux produit avec statistiques à jour
|
|
- [ ] Phase 2 : doublons, patterns, dates relatives, orphelines — tous scannés
|
|
- [ ] Phase 3 : fusions faites, synthèses créées, orphelines rattachées
|
|
- [ ] Phase 4 : VAULT-INDEX.md à jour et sous 200 lignes
|
|
- [ ] Phase 4 : dream-log.md mis à jour avec toutes les actions
|
|
- [ ] Phase 4 : propositions de nettoyage listées (sans action automatique)
|
|
- [ ] Aucun contenu original supprimé ou altéré
|
|
- [ ] Toutes les notes touchées ont `updated` à jour
|
|
- [ ] Tous les `source_llm` originaux sont préservés
|