deamon-vault/_adn/skills/obsidian-note-creator.md

name

description

obsidian-note-creator

Crée des notes Obsidian (.md) optimisées avec frontmatter YAML structuré, tags normalisés, liens internes et templates adaptés. Les notes sont pensées pour être créées ET lues par des LLM en autonomie via un MCP Obsidian. Utilise cette skill dès qu'on te demande de créer une note, fiche, entrée de journal, résumé de veille, brief de contenu, note de projet, ou tout document destiné à un vault Obsidian. Déclenche aussi quand l'utilisateur mentionne "note", "fiche", "vault", "Obsidian", "knowledge base", "base de connaissances", ou veut sauvegarder/structurer une information pour la retrouver plus tard — même s'il ne dit pas explicitement "Obsidian". Déclenche également pour l'import ou le mapping de notes depuis Notion vers Obsidian.

Obsidian Note Creator

Tu es un LLM qui crée des notes Markdown dans un vault Obsidian en totale autonomie. Ce vault sert de cerveau partagé entre plusieurs LLM (Claude, ChatGPT, Gemini, modèles locaux…) via un MCP Obsidian. Les notes que tu crées seront lues et exploitées par d'autres LLM autant que par l'humain.

Chaque note doit être autonome (compréhensible seule par n'importe quel LLM), découvrable (trouvable par recherche, tags ou liens), et structurée de façon machine-friendly (frontmatter YAML rigoureux et contenu clair).

Première chose à faire : lire BRAIN.md

Avant de créer toute note, vérifie si un fichier BRAIN.md existe dans _adn/ à la racine du vault. Ce fichier contient le profil de l'utilisateur : qui il est, ses outils, sa config technique (PC, serveur, services), ses objectifs, ses préférences, ses projets en cours. C'est l'équivalent d'un CLAUDE.md mais cross-LLM — chaque LLM qui se connecte au vault le lit en premier.

Si ce fichier existe, lis-le et adapte la note en conséquence (vocabulaire, contexte projet, liens vers les projets actifs, etc.). Si tu n'y as pas accès, crée la note quand même avec les informations disponibles.

Philosophie

L'approche combine le meilleur de Zettelkasten (notes atomiques interconnectées) et PARA (organisation par cycle de vie) sans imposer de rigidité. L'idée centrale : une note = une idée claire, avec suffisamment de contexte et de métadonnées pour qu'un agent IA puisse la retrouver, la comprendre et l'exploiter sans avoir besoin de lire tout le vault.

Les notes sont pensées pour survivre au temps et aux changements de LLM. Dans 6 mois, un LLM complètement différent doit pouvoir ouvrir cette note et comprendre exactement de quoi il s'agit, pourquoi elle existe, et comment elle se relie au reste.

Un LLM ne "navigue" pas dans des dossiers — il cherche par métadonnées, tags et liens. La structure de dossiers sert surtout à l'humain quand il ouvre Obsidian visuellement. Le vrai pouvoir d'organisation repose sur le frontmatter YAML, les tags hiérarchiques et les liens [[...]].

Structure du vault

vault/
├── _adn/        # BRAIN.md, conventions, config du vault
├── inbox/          # Notes fraîches — tout atterrit ici, les LLM trient après
├── projects/       # Notes liées à des projets actifs (OpenClaw, chaîne YouTube…)
├── knowledge/      # Veille techno, fiches de compétences, références, apprentissages
├── content/        # Idées et briefs de contenu (YouTube, Instagram, blog)
├── journal/        # Daily notes, réflexions personnelles
├── decisions/      # Historique des décisions avec contexte et raisonnement
└── moc/            # Maps of Content — index thématiques auto-générés

Cette structure est volontairement simple : 7 dossiers qui correspondent aux flux réels de travail. Les catégories fines (business, coaching, tech/ia, perso/habitudes…) sont gérées par les tags, pas par les dossiers. C'est plus flexible et c'est ce que les LLM exploitent pour chercher.

Place les notes dans le bon dossier selon leur nature. En cas de doute, utilise inbox/ — un passage de tri ultérieur (skill obsidian-organizer) s'en chargera.

Pipeline : capturer à chaud, organiser à froid

Les notes sont créées selon un pipeline en 3 temps :

1. Temps réel (pendant les conversations) — Dès qu'une information mérite d'être conservée (décision, idée, veille, apprentissage…), le LLM crée la note immédiatement dans inbox/. Le contexte est frais, rien ne se perd. Si le type et le dossier cible sont évidents, le LLM peut placer directement dans le bon dossier — sinon, inbox/ par défaut.

2. Passe du soir (avant autodream) — La skill obsidian-organizer fait une passe quotidienne : elle trie les notes restées dans inbox/, enrichit les liens [[...]] entre notes de la journée, détecte les connexions avec les notes existantes, et vérifie la conformité des tags et du frontmatter.

3. Autodream (consolidation) — La skill obsidian-dream consolide à plus grande échelle : fusion de doublons, mise à jour des MOC, détection de patterns sur plusieurs jours/semaines.

L'idée : chaque LLM capture l'info au moment où il l'a, sans se soucier de l'organisation parfaite. L'organisation vient après, à froid, quand on peut prendre du recul sur l'ensemble.

Frontmatter YAML obligatoire

Chaque note commence par un bloc frontmatter YAML. C'est le cœur de la découvrabilité — un agent IA qui parcourt le vault s'appuie principalement sur ces métadonnées pour décider si une note est pertinente.

---
title: "Titre clair et descriptif"
type: project | resource | idea | decision | daily | meeting | inbox
created: 2026-04-07T14:30:00
updated: 2026-04-07T14:30:00
tags:
  - domaine/sous-domaine
  - statut/actif
status: draft | active | review | done | archived
summary: "Une phrase de 20-50 mots — un LLM doit pouvoir décider si cette note est pertinente en lisant uniquement ce champ"
source_llm: claude | chatgpt | gemini | local | human
related:
  - "[[Nom de note liée]]"
---

Champs détaillés

title — Descriptif et spécifique. Pas "Notes réunion" mais "Décision architecture auth OpenClaw - JWT vs sessions". Un bon titre permet de comprendre le contenu sans ouvrir la note.

type — Catégorise la note :

• project : liée à un projet avec un début et une fin
• resource : fiche de connaissance, veille techno, compétence, référence
• idea : idée à explorer, concept, brainstorm, brief de contenu
• decision : décision prise avec contexte et raisonnement
• daily : entrée de journal quotidien
• meeting : notes de réunion ou échange
• inbox : note brute pas encore catégorisée

tags — Hiérarchiques avec / comme séparateur. Toujours en minuscules, sans accents, avec des tirets pour les espaces. Conventions :

# Domaines
domaine/tech, domaine/tech/ia, domaine/tech/3d-printing, domaine/tech/devops
domaine/business, domaine/coaching, domaine/content
domaine/perso, domaine/perso/habitudes, domaine/perso/journal

# Statuts (gère le cycle de vie, y compris l'archivage)
statut/actif, statut/draft, statut/review, statut/done, statut/archive

# Types de contenu
contenu/youtube, contenu/instagram, contenu/blog

# Priorité (optionnel)
priorite/haute, priorite/moyenne, priorite/basse

# Projets (préfixe projet/)
projet/openclaw, projet/chaine-youtube

# Source d'import (si la note vient d'ailleurs)
import/notion, import/web, import/manual

Utilise 2 à 5 tags par note. Au moins un tag de domaine doit être présent.

status — Cycle de vie de la note. Les notes archivées gardent statut/archive en tag et restent dans leur dossier (pas de dossier "archives" séparé).

summary — Le champ le plus important pour l'exploitation IA. Écris une phrase complète de 20-50 mots qui permettrait à un agent de décider "est-ce que cette note m'est utile ?" sans l'ouvrir. Pas un titre bis, mais un vrai résumé du contenu et de sa valeur.

source_llm — Le LLM qui écrit la note. C'est simple : tu es Claude, tu mets claude. Si c'est ChatGPT qui crée la note via le MCP, il met chatgpt. Si c'est Gemini, gemini. Si l'humain écrit directement, human. Ça trace qui a produit quoi dans le vault, pour la traçabilité cross-LLM.

source_conversation (optionnel) — L'URL de la conversation qui a généré cette note. Permet de retrouver l'échange original si besoin. La note doit rester autoporteuse (compréhensible sans ouvrir le lien) — ce champ sert uniquement de référence pour reprendre la discussion.

source_conversation: "https://claude.ai/chat/abc123"
# ou : "https://chatgpt.com/c/xyz789"

related — Liens Obsidian vers les notes connexes. Utilise la syntaxe [[Nom]]. Même 1-2 liens rendent la note beaucoup plus découvrable en créant du tissu dans le graphe.

Champs optionnels selon le type

Pour type: project :

project_name: "OpenClaw"
project_phase: planning | building | testing | deployed | paused
deadline: 2026-06-01

Pour type: decision :

decision: "Utiliser JWT plutôt que sessions pour l'auth"
alternatives_considered:
  - "Sessions serveur avec Redis"
  - "OAuth2 délégué"
confidence: high | medium | low
reversible: true | false

Pour type: daily :

mood: 😊 | 😐 | 😔
energy: high | medium | low
wins: ["Terminé le MCP Gmail", "Sport fait"]

Pour les notes de veille (type: resource + tag domaine/tech/*) :

source_url: "https://..."
source_type: article | video | paper | doc | tweet | podcast
relevance: high | medium | low

Pour les notes importées depuis Notion :

source_notion: "URL ou page ID Notion d'origine"
imported_at: 2026-04-07T14:30:00
notion_properties: {}  # Propriétés Notion originales conservées pour référence

Import et mapping Notion → Obsidian

Quand tu importes une note depuis Notion, tu ne fais pas un copier-coller. Ton rôle est d'enrichir la note en l'intégrant dans le tissu du vault :

Étapes du mapping

1. Lire la note Notion et comprendre son contenu, son type, et ses propriétés (status, tags, dates…)

2. Mapper les propriétés Notion → frontmatter YAML :

   • Les colonnes/propriétés Notion deviennent des champs YAML ou des tags
   • Les statuts Notion → status + tag statut/...
   • Les tags/catégories Notion → tags hiérarchiques domaine/...
   • Les dates Notion → created, deadline, etc.
   • Conserver les propriétés originales dans notion_properties pour référence

3. Assigner le bon type en analysant le contenu (pas juste la structure Notion) :

   • Une page projet Notion → type: project
   • Une page wiki/docs Notion → type: resource
   • Une entrée de journal Notion → type: daily
   • etc.

4. Créer des liens [[...]] vers les notes existantes du vault :

   • Chercher les notes qui partagent les mêmes tags ou projets
   • Identifier les connexions sémantiques (même sujet, même domaine)
   • Relier aux MOC pertinentes
   • C'est ici que l'IA apporte de la valeur : faire des rapprochements que l'humain ne fait pas

5. Placer dans le bon dossier selon le type, pas selon la structure Notion d'origine

6. Ajouter les tags d'import : import/notion + source_notion dans le frontmatter

Exemple de mapping

Notion page avec propriétés Status: In Progress, Category: Tech, Tags: AI, MCP :

---
title: "..."
type: resource
status: active
tags:
  - domaine/tech/ia
  - projet/openclaw        # ← connexion détectée par l'IA
  - import/notion
  - statut/actif
source_llm: claude
source_notion: "https://notion.so/page-id"
imported_at: 2026-04-07T14:30:00
notion_properties:
  status: "In Progress"
  category: "Tech"
  tags: ["AI", "MCP"]
---

Structure du contenu Markdown

Après le frontmatter :

# Titre de la note

> [!summary]
> Résumé en 2-3 phrases. Reprend et développe le champ `summary` du frontmatter.

## Contenu principal

Le corps de la note. Varie selon le type (voir templates ci-dessous).

## Liens et contexte

- Relié à : [[Note 1]], [[Note 2]]
- Voir aussi : [[MOC pertinente]]

Callouts Obsidian utiles

> [!tip] Point clé
> L'information la plus importante à retenir.

> [!warning] Attention
> Un piège ou une subtilité à ne pas oublier.

> [!question] À explorer
> Un point qui mérite investigation.

> [!decision] Décision prise
> Ce qui a été décidé et pourquoi.

Templates par type de note

Note de veille techno

---
title: "[Sujet] - [Source courte]"
type: resource
tags: [domaine/tech/sous-domaine, statut/actif]
source_url: ""
source_type: article
relevance: medium
summary: ""
source_llm: claude
source_conversation: ""
---

# [Titre]

> [!summary]
> Résumé.

## Points clés

- Point 1
- Point 2

## Implications pour mes projets

Comment ça s'applique concrètement à mon travail ou mes projets.

## Liens

- [[MOC pertinente]]

Note de projet

---
title: "[Nom projet] - [Aspect spécifique]"
type: project
project_name: ""
project_phase: planning
tags: [projet/nom-projet, domaine/..., statut/actif]
summary: ""
source_llm: claude
---

# [Titre]

> [!summary]
> Résumé.

## Contexte

Pourquoi cette note existe dans le cadre du projet.

## Contenu

Le détail.

## Prochaines étapes

- [ ] Action 1
- [ ] Action 2

## Décisions prises

| Date | Décision | Raison | LLM |
|------|----------|--------|-----|
| 2026-04-07 | ... | ... | claude |

## Liens

- [[Projet principal]]

Journal quotidien (Daily note)

---
title: "Journal - 2026-04-07"
type: daily
tags: [domaine/perso/journal, statut/actif]
mood: 😊
energy: high
wins: []
summary: "Résumé de la journée du 2026-04-07"
source_llm: human
---

# Journal — 7 avril 2026

## Comment je me sens

Libre expression.

## Ce que j'ai accompli

- ...

## Ce que j'ai appris

- ...

## Demain

- ...

Fiche de compétence

---
title: "[Compétence] - [Aspect]"
type: resource
tags: [domaine/coaching|projects/sous-domaine, statut/actif]
summary: ""
source_llm: claude
---

# [Titre]

> [!summary]
> Résumé.

## Concept

Explication claire du concept ou de la compétence.

## Application pratique

Comment l'utiliser concrètement.

## Exemples

Des cas concrets.

## Liens

- [[MOC Compétences]]

Idée de contenu

---
title: "[Plateforme] - [Titre de l'idée]"
type: idea
tags: [contenu/youtube|instagram|blog, domaine/content, statut/draft]
summary: ""
source_llm: claude
---

# [Titre]

> [!summary]
> L'idée en bref.

## Le concept

De quoi ça parle, quel angle.

## Public cible

À qui ça s'adresse.

## Points clés à couvrir

- ...

## Hook / Accroche

Proposition d'accroche.

## Liens

- [[MOC Contenu]]

Note de décision

---
title: "Décision - [Sujet clair]"
type: decision
decision: "[La décision en une phrase]"
alternatives_considered:
  - "Alternative 1 (raison du rejet)"
  - "Alternative 2 (raison du rejet)"
confidence: high
reversible: true
tags: [projet/nom-projet, domaine/..., statut/actif]
summary: ""
source_llm: claude
---

# Décision : [Sujet]

> [!summary]
> Résumé.

> [!decision] Décision
> [La décision en clair]

## Contexte

Pourquoi cette décision devait être prise.

## Raisonnement

Le détail du raisonnement et des arguments.

## Alternatives écartées

| Alternative | Raison du rejet |
|---|---|
| ... | ... |

## Implications

Ce que cette décision change concrètement.

## Liens

- [[Projet concerné]]

Règles de nommage des fichiers

• Tout en minuscules, tirets pour les espaces, pas d'accents
• Préfixe date pour les daily notes : 2026-04-07-journal.md
• Descriptif pour le reste : decision-auth-jwt-openclaw.md, veille-ia-mcp-protocol.md
• Pas de numérotation arbitraire

Liens internes

Crée des liens [[...]] généreusement. Chaque note devrait pointer vers au moins 1-2 autres notes. Les bons candidats :

• La MOC du domaine concerné
• Les notes de projet liées
• Les notes qui explorent le même concept sous un angle différent
• Les décisions qui ont influencé cette note

Quand tu crées une note, cherche activement dans le vault des notes existantes qui pourraient être liées. C'est une des valeurs ajoutées principales de l'IA : faire des connexions que l'humain ne fait pas.

Checklist de qualité (vérifie CHAQUE point avant de finaliser)

• Le summary du frontmatter est une vraie phrase exploitable de 20-50 mots
• Au moins 2 tags dont un tag de domaine (domaine/...)
• source_llm = le LLM qui écrit cette note (toi)
• created et updated sont des dates absolues ISO 8601
• Au moins 1 lien interne [[...]]
• Le fichier est nommé correctement (minuscules, tirets, descriptif, pas d'accents)
• Le contenu est autonome — compréhensible sans lire d'autres notes
• Placé dans le bon dossier du vault
• Pour type: decision : decision, alternatives_considered, confidence, reversible renseignés
• Pour les notes de veille : source_url et source_type renseignés
• Si import Notion : source_notion, imported_at, import/notion tag, et notion_properties renseignés
• Si créé pendant une conversation : source_conversation renseigné avec l'URL de l'échange