LucioLiu/user-md

user-md : Discipline du fichier de profil utilisateur

Votre IA doit comprendre qui vous êtes via un fichier que vous possédez — pas verrouillé dans un cloud propriétaire. Ce document définit la discipline du fichier de profil (comment le créer, le maintenir et l'utiliser avec un agent), pas un système de mémoire (sans exécution ni pipeline automatique). Les détails se trouvent dans references/ : règles de maintenance curation.md, critères de stratification et relations hôte layering.md. Les seuils de volume et de fréquence pour l'ensemble des fichiers ne sont définis qu'une seule fois dans le tableau des seuils de references/curation.md ; ce fichier et les autres se contentent de les référencer, sans les copier.

Position centrale (quatre phrases)

1. Vous possédez le fichier : Markdown clair, lisible et modifiable dans n'importe quel éditeur, déplaçable avec vos dossiers (moves when you move).
2. Deux voies distinctes : La section manuscrite vous appartient, l'agent ne peut que suggérer, jamais réécrire ; la section d'apprentissage appartient à l'agent, avec des ajouts uniquement en mode append et chaque ligne tracée.
3. Pas de réécriture silencieuse : Toute modification laisse une trace (une ligne dans le journal des changements) ; tout le contenu est visible, modifiable et supprimable par vous.
4. Pas d'invention de faits : La section d'apprentissage ne contient que des observations réelles, chaque observation unique doit être marquée comme « à vérifier » ; rien n'est écrit sans avoir été observé.

I. Création : Famille de fichiers et cinq sections

Les trois fichiers de la famille

Fichier	Contenu	Caractéristiques
USER.md	Profil utilisateur valable sur toutes les machines et tous les projets	Portable ; injecté en entier à chaque session, doit rester léger (seuils dans references/curation.md)
USER.local.md	Contenu qui perd sa validité sur une autre machine : environnement, chemins, chaînes d'outils, références de credentials	Local à la machine ; doit être dans .gitignore
user/*.md Fichiers auxiliaires de débordement	Détails déplacés de la section d'apprentissage quand elle dépasse la ligne de flottaison	Le fichier principal conserve une ligne d'index, chargement à la demande

Les cinq sections de USER.md (structure définitive, modèle dans templates/USER.md)

1. ## Who I am — Faits d'identité : rôle, parcours, comment vous voulez être appelé. Faits et préférences séparés (séparer les deux types d'information est une pratique courante des systèmes de mémoire professionnels).
2. ## How I work — Préférences et style : mode de communication, normes de livrables, habitudes de validation, limites d'autorisation par défaut.
3. ## Our relationship — Relation et collaboration : ce qui doit être demandé, ce qui peut être fait directement, comment donner du feedback.
4. ## What I'm up to — Couche de perception dynamique : objectifs actuels et tâches en cours — hypothèses explicitement révisables, mises à jour avec les preuves, supprimées quand obsolètes.
5. ## Learned by your agent — Zone d'apprentissage de l'agent (voir les règles de la section II sur le système à deux voies).

Règle de nommage : Les titres suivent le spectre faits/préférences ; le mot "persona" est interdit dans tout le document — en UX, il désigne un utilisateur fictif ; dans le contexte agent, il désigne la personnalité de l'agent lui-même. Double usage = ambiguïté.

Pour commencer : Copiez les deux modèles de templates/ à la racine de votre espace de travail, ajoutez USER.local.md dans .gitignore, et passez cinq minutes à remplir les quatre premières sections. Laisser vide fonctionne, mais l'agent n'aura aucune connaissance de vous à chaque session.

II. Maintenance : Système à deux voies et discipline d'apprentissage

Système à deux voies

• Zone manuscrite (quatre premières sections) : Écrite par vous. Si l'agent trouve du contenu obsolète ou contradictoire, il peut seulement suggérer (texte de suggestion + raison) ; vous modifiez vous-même après accord explicite, puis ajoutez une ligne dans le journal des changements à la fin du fichier.

• Zone d'apprentissage (section 5) : Ajouts par l'agent. Chaque entrée suit ce format :

  - 【AAAA-MM-JJ · Événement source】Texte de la règle.【Observation unique à vérifier】

  La date + la source sont l'acte de naissance de chaque entrée ; toute observation unique doit porter la mention "à vérifier". Si des observations similaires se répètent jusqu'à atteindre le seuil de promotion (voir references/curation.md), l'agent peut proposer une promotion vers la zone manuscrite, uniquement après votre confirmation. Format complet et procédure dans references/curation.md.

Signaux et faux positifs

• Trois types de signaux exploitables : correction (vous corrigez une action ou une compréhension de l'agent), préférence répétée (même type de demande dans différents contextes), expression explicite (vous dites « souviens-toi », « toujours faire comme ça », etc.).
• Ajout immédiat en dur : Si un signal correspond à l'un des trois types et passe le filtre anti-faux positifs → ajoutez immédiatement dans la zone d'apprentissage — pas de regroupement, pas d'attente de la fin de session pour écrire de mémoire. Si vous reconnaissez le signal mais ne l'écrivez pas, cette discipline est inutile.
• Filtre anti-faux positifs : Les contextes uniques ne sont pas ajoutés (exigence spécifique à une tâche ≠ préférence durable) ; les messages très courts sont ignorés par défaut (seuil dans references/curation.md) ; les expressions émotionnelles sont stockées avec une confiance réduite ; les instructions liées à une tâche spécifique restent dans la tâche, pas dans le profil.

Consolidation et volume

• Consolidation régulière et déduplication (période dans le tableau des seuils de references/curation.md) : Fusion des entrées synonymes, nettoyage des obsolètes ; la consolidation et la promotion vers la zone manuscrite sont les deux seuls cas légitimes de réécriture de la zone d'apprentissage, chaque opération laisse une trace dans le journal des changements.
• Si le fichier principal dépasse le volume cible ou si la zone d'apprentissage dépasse la ligne de flottaison (seuils dans references/curation.md) → les détails sont déplacés vers les fichiers auxiliaires user/*.md, le fichier principal conserve une ligne d'index.

III. Utilisation : Injection et répartition

Injection à chaque session

C'est pourquoi le fichier principal doit rester léger : assez petit pour être injecté en entier à chaque session. Selon l'hôte, choisissez l'une des méthodes suivantes (détails dans la section Compatibilité du README) :

• Ligne de référence dans un fichier d'instructions : Par exemple, ajoutez @USER.md dans CLAUDE.md pour Claude Code.
• Hôte sans mécanisme de référence : Ajoutez une phrase dans l'invite système ou le fichier de règles : « Au début de chaque session, lisez USER.md ».
• Hook session-start possible (optionnel — ce skill ne fournit aucun runtime, la discipline reste valide sans hook). Exemple de configuration pour Claude Code :

{
  "hooks": {
    "SessionStart": [
      { "hooks": [ { "type": "command", "command": "cat USER.md" } ] }
    ]
  }
}

(Exemple POSIX ; adaptez sous Windows ou autre hôte. L'activation et la configuration sont à votre discrétion.)

Trois règles de répartition (modèle faible comme filet de sécurité, voir references/layering.md)

1. Perte de validité sur une autre machine → USER.local.md.
2. Perte de validité dans un autre projet ou rôle → fichier local de ce projet.
3. Sinon → USER.md.

Règle de pointeur : Ne recopiez pas les faits qui ont déjà une source faisant autorité ; utilisez simplement une ligne de pointeur ("voir fichier X") — évite la dérive de double source. Exemples dans references/layering.md.

Ligne rouge de la confidentialité

• Cette famille de fichiers contient naturellement des données personnelles — traitez-les comme vos informations les plus sensibles.
• USER.local.md doit être dans .gitignore, jamais dans un dépôt.
• Avant de pousser USER.md dans un dépôt public, vérifiez-le manuellement : nom réel, coordonnées, informations internes sur l'employeur, références de credentials.
• Ne jamais écrire de mots de passe en clair, de clés API ou de tokens dans cette famille de fichiers — uniquement des pointeurs ("où sont les credentials, comment les appeler").
• Les modèles ne contiennent jamais de données réelles — les modèles fournis avec ce skill sont tous des espaces réservés et des exemples fictifs.

Exemples rapides

• Vous dites encore « commencez par la conclusion ». Si les entrées similaires dans la zone d'apprentissage atteignent le seuil de promotion (voir references/curation.md) → proposez une promotion (fusionnez en une phrase, classez dans How I work), attendez votre confirmation.
• Vous dites « sur cette machine, utilisez pnpm, pas npm » → condition perdue sur autre machine → écrivez dans USER.local.md.
• Vous dites dans un dépôt particulier « les messages de commit de ce projet doivent être en espagnol » → condition perdue sur autre projet → écrivez dans le fichier local de ce projet, pas dans USER.md.
• Vous vous plaignez tard le soir « ça suffit, plus de longs messages » → moment émotionnel → stockez comme observation unique avec confiance réduite, ne modifiez pas la zone manuscrite directement, encore moins comme règle absolue.
• Vous avez écrit « je travaille sur le projet X » dans la zone manuscrite mais vous ne l'avez pas mentionné depuis trois mois → l'agent suggère de mettre à jour la section What I'm up to, avec justification ; pas de changement sans votre accord explicite.

Version et mise à jour

• Version actuelle : 1.0.0 (correspond à plugin.json).
• Dépôt : https://github.com/LucioLiu/user-md
• Vérification : Si installé via plugin, le mécanisme de mise à jour de l'hôte suit le numéro de version ; si cloné manuellement ou copié depuis les modèles, comparez ce fichier avec la branche main du dépôt pour savoir si vous êtes à jour. Votre propre famille USER.md n'est pas affectée par les mises à jour du skill — ce sont vos données, pas une partie du skill.