Files
context-continuity/skill_trilium_continuity.md
T
Master 01629780f4 chore: versioning initial du systeme Context Continuity
Code du systeme de memoire multi-LLM sur Trilium :
- trilium_api.py : wrapper trilium-py (notes, labels, relations)
- mcp_server.py : serveur MCP Starlette (19 tools, OAuth + Bearer)
- api_context.py : API REST FastAPI
- trilium_context.py : workflow CLI
- watchdog.sh, start_*.sh : supervision et demarrage
- skills, docs et ontologie associes
Secrets (.env, oauth_state.json) exclus via .gitignore.
2026-06-29 11:02:22 +02:00

5.4 KiB

SKILL — Réflexe de continuité Trilium

Skill universel de mémoire de projet. Décrit quand lire le contexte et quand capitaliser proactivement dans Trilium au fil d'une session. Orienté comportement — le « comment » technique est dans le skill de référence API Trilium.

Réutilisable pour tout projet suivi dans le système Context Continuity (Trilium comme base pivot, partagée entre Claude et Le Chat).


Le principe

Trilium est la mémoire longue du projet, partagée entre LLMs. Une conversation ne doit jamais être la seule détentrice d'une décision ou d'un fait : tout ce qui compte est capitalisé dans Trilium au fil de l'eau, pour qu'une nouvelle conversation (même sur un autre LLM) puisse reprendre sans perte.

L'agent ne se contente pas de répondre : il tient la mémoire à jour proactivement aux moments clés, et lit le contexte en début de session.


Deux chemins d'accès selon le LLM

Côté Le Chat (Mistral) : accès natif via MCP. Les tools (get_contexte, add_decision, add_history, etc.) sont appelés directement par l'agent.

Côté Claude : le connecteur MCP n'est pas disponible (le serveur n'implémente pas OAuth, requis par Claude). L'accès se fait donc par relais humain : l'agent propose à Bastien la commande exacte à lancer, Bastien l'exécute sur GrosseBertha et colle le retour. C'est transparent côté comportement — seul le mécanisme diffère.

Quand l'OAuth sera ajouté au serveur MCP, Claude pourra accéder directement et ce relais deviendra inutile.


EN DÉBUT DE SESSION — lire le contexte

Au démarrage d'une session sur un projet existant, récupérer le briefing de reprise avant de travailler :

  • Le Chat : appeler le tool get_contexte(projet="SlidingAutomation", llm_cible="Le Chat Large").
  • Claude : proposer à Bastien :
    python trilium_context.py generate-context --projet SlidingAutomation --llm-cible "Claude Sonnet" --note-id <ID_DERNIERE_CONV> --version <N>
    
    puis lire le briefing qu'il colle.

Le briefing contient : décisions actives, historique valide, glossaire, backlog actif. Confirmer en 3 lignes : (a) objectif, (b) prochaine action, (c) incertitude — avant de continuer.

Optionnel mais recommandé : créer la note de conversation dès le début (new_conversation) pour pouvoir la clôturer ensuite.


PENDANT LA SESSION — capitaliser aux moments clés

L'agent surveille activement ces déclencheurs et propose la capitalisation sans attendre la fin :

Déclencheur : une décision est actée

Dès qu'un choix technique ou architectural est tranché (« on fait X plutôt que Y ») :

  • Le Chat : add_decision(projet, enonce, justification)
  • Claude : proposer
    python trilium_context.py add-decision --projet SlidingAutomation --enonce "Énoncé court et actionnable" --justification "Pourquoi ce choix"
    

Déclencheur : un test est effectué ou une contrainte découverte

Dès qu'un test valide/invalide quelque chose, ou qu'une limite est rencontrée :

  • Le Chat : add_history(projet, enonce, type_historique, detail)
  • Claude : proposer
    python trilium_context.py add-history --projet SlidingAutomation --type "Test effectue" --enonce "Ce qui a été testé" --detail "Résultat observé"
    

type_historique ∈ { Fait etabli, Test effectue, Hypothese invalidee, Contrainte decouverte } (sans accent, exactement ces libellés).

Déclencheur : une tâche future émerge

Dès qu'un « il faudra faire X » apparaît :

  • Le Chat : add_backlog(projet, titre, priorite)
  • Claude : proposer la commande équivalente. priorite ∈ { haute, moyenne, basse }.

Déclencheur : une tâche change d'état

Quand un item passe en cours / fait / bloqué : update_backlog(note_id, statut). statut ∈ { a faire, en cours, bloque, fait, abandonne }.


EN FIN DE SESSION — clôturer

Quand Bastien signale que la limite de tokens approche (l'agent se répète, oublie une contrainte, perd en précision), produire une synthèse de clôture de 150-200 mots, format concis sans markdown complexe :

Synthèse de clôture :
- Objectif de la session : ...
- Accompli : ...
- En cours : ...
- Bloqué : ...
- Prochaine action : ...

Puis l'enregistrer :

  • Le Chat : close_session(note_id, synthese)
  • Claude : proposer
    python trilium_context.py close-session --note-id <ID_CONV> --summary "COLLE ICI LA SYNTHÈSE"
    

Enfin, générer le briefing de reprise (generate-context) pour la prochaine session ou la bascule vers l'autre LLM.


Règles de capitalisation — à respecter strictement

Ces règles évitent que les filtres de Trilium ratent les notes :

  • Nom de projet sans espaces : SlidingAutomation, jamais Sliding Automation.
  • Valeurs de statut en minuscules : actif, active, a faire — jamais de majuscule.
  • encoreValide : true / false en minuscules.
  • typeHistorique : exactement un des 4 libellés sans accent.
  • Énoncés courts et actionnables — une ligne, pas un paragraphe.

Posture de l'agent

Capitaliser n'est pas optionnel ni réservé à la fin. L'agent propose l'enregistrement au moment où l'information naît, brièvement (« Je note cette décision dans Trilium ? » + la commande prête). Il n'attend pas que Bastien le demande. La mémoire du projet est une responsabilité continue, pas une corvée de clôture.