Vous étendez un système de connaissances existant avec un nouveau domaine. Il s'agit de composition, pas de remplacement. Le nouveau domaine doit coexister avec les domaines existants tout en conservant son propre vocabulaire, son schéma et ses modèles de traitement. Le graphe partagé (liens wiki, hub MOC, champs de description) connecte le tout.
Votre tâche
Ajouter un nouveau domaine de connaissance : $ARGUMENTS
Fichiers de référence
Lisez ces fichiers lors des phases de dérivation :
Règles de composition :
${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md-- Le test 4 (Composition multi-domaine) valide le modèle${CLAUDE_PLUGIN_ROOT}/reference/three-spaces.md-- Architecture en trois espaces (partagée entre les domaines)${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md-- Validation de cohérence pour la configuration du domaine
Configuration du domaine :
${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md-- Mappage des termes natifs du domaine${CLAUDE_PLUGIN_ROOT}/reference/tradition-presets.md-- Configurations de domaine pré-validées${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md-- 3 préréglages avec configurations${CLAUDE_PLUGIN_ROOT}/reference/dimension-claim-map.md-- Fondement de la recherche pour les positions des dimensions${CLAUDE_PLUGIN_ROOT}/reference/failure-modes.md-- Matrice de vulnérabilité du domaine
Validation :
${CLAUDE_PLUGIN_ROOT}/reference/kernel.yaml-- Les 12 primitives non-négociables${CLAUDE_PLUGIN_ROOT}/reference/validate-kernel.sh-- Script de validation du noyau
PHASE 1 : Analyse du système existant
Automatisée. Comprendre ce qui existe avant d'y ajouter quelque chose.
1a. Lire la configuration système
Lire ops/derivation.md pour :
- Positions actuelles des dimensions
- Mappage du vocabulaire
- Niveau de plateforme et d'automatisation
- Blocs de fonctionnalités actifs
Lire ops/config.yaml pour les valeurs de configuration en direct.
1b. Inventaire des domaines existants
Identifier tous les domaines de connaissance actuels :
- Dossier de notes principal et son vocabulaire de domaine
- Tout domaine secondaire existant (dossiers, modèles, MOC)
- Champs de schéma utilisés par domaine
1c. Identifier les types de dimensions
Classer chacune des 8 dimensions comme niveau système ou ajustable par domaine :
| Dimension | Type | Justification |
|---|---|---|
| Organisation | niveau système | Plat/hiérarchique s'applique à l'ensemble de l'espace de travail |
| Automatisation | niveau système | Les hooks et les compétences sont une infrastructure à l'échelle de l'espace de travail |
| Profondeur de navigation | niveau système | La structure du hub MOC est partagée |
| Granularité | ajustable par domaine | Différents domaines peuvent nécessiter différentes granularités |
| Traitement | ajustable par domaine | La recherche nécessite un traitement lourd, les relations un traitement léger |
| Maintenance | ajustable par domaine | Différents seuils de condition par taux de croissance du domaine |
| Schéma | ajustable par domaine | Les champs spécifiques au domaine varient |
| Liaison | ajustable par domaine | Certains domaines nécessitent une recherche sémantique, d'autres non |
Les dimensions de niveau système sont fixées par le système existant. Les dimensions ajustables par domaine peuvent varier pour le nouveau domaine.
PHASE 2 : Conversation
1 à 3 tours de conversation pour comprendre le nouveau domaine. Utilisez AskUserQuestion pour chaque tour.
Question d'ouverture
Posez UNE question ciblée sur le nouveau domaine :
« Parlez-moi de [indice de domaine de $ARGUMENTS] — quel genre de choses allez-vous suivre, et quel est le rapport avec votre travail existant sur [vocabulaire du domaine actuel] ? »
La seconde moitié est cruciale : comprendre la relation entre les domaines guide les décisions de composition.
Extraction de signaux
Au fur et à mesure que l'utilisateur répond, extrayez des signaux pour les dimensions ajustables par domaine :
| Signal | Dimension | Position |
|---|---|---|
| « Notes rapides sur les personnes » | Granularité | modérée |
| « Analyse approfondie des sessions » | Traitement | lourd |
| « Juste me souvenir des moments clés » | Traitement | léger |
| « Je reviens et je mets à jour souvent » | Maintenance | seuils stricts |
| « La plupart du temps statique une fois capturé » | Maintenance | seuils souples |
| « Besoin de trouver des motifs entre les entrées » | Liaison | explicite+implicite |
Extrayez également :
- Estimation du volume -- combien de notes par lot de traitement
- Dynamique temporelle -- à quelle vitesse le contenu change-t-il
- Vocabulaire -- les propres mots de l'utilisateur pour les notes, processus, organisation
- Relation inter-domaines -- comment cela se connecte au(x) domaine(s) existant(s)
Stratégie de suivi
Après la réponse d'ouverture, posez 1 à 2 questions de suivi ciblant :
- Confirmation du vocabulaire -- « Quand vous dites [mot de l'utilisateur], voulez-vous dire des idées individuelles ou des entrées plus longues ? »
- Modèles de connexion inter-domaines -- « Les notes [nouveau domaine] se connecteront-elles à vos notes [domaine existant] ? Comment ? »
Ne posez PAS de questions directes sur les dimensions. Écoutez-les dans la conversation naturelle.
PHASE 3 : Dériver la configuration du domaine
3a. Mapper les signaux aux dimensions ajustables par domaine
Pour chaque dimension ajustable, déterminez la position pour le nouveau domaine :
- Signaux de l'utilisateur (priorité la plus élevée)
- Préréglage de cas d'utilisation le plus proche de
${CLAUDE_PLUGIN_ROOT}/reference/use-case-presets.md - Cascade à partir des dimensions de niveau système
3b. Construire le mappage du vocabulaire
Lisez ${CLAUDE_PLUGIN_ROOT}/reference/vocabulary-transforms.md pour la table de transformation.
Ordre de priorité :
- Mots de l'utilisateur issus de la conversation
- Vocabulaire du préréglage de cas d'utilisation
- Mélange du domaine de référence le plus proche
Construisez le mappage complet pour le nouveau domaine :
| Terme universel | Terme du nouveau domaine | Source |
|---|---|---|
| note | [terme] | [utilisateur / préréglage / mélange] |
| extraire / réduire | [terme] | [utilisateur / préréglage / mélange] |
| connecter / réfléchir | [terme] | [utilisateur / préréglage / mélange] |
| MOC | [terme] | [utilisateur / préréglage / mélange] |
| description | [terme] | [utilisateur / préréglage / mélange] |
| sujets | [terme] | [utilisateur / préréglage / mélange] |
| boîte de réception | [terme] | [utilisateur / préréglage / mélange] |
3c. Concevoir le schéma spécifique au domaine
Partez du schéma de note de base (description, sujets) et ajoutez des champs spécifiques au domaine :
_schema:
entity_type: "[domaine]-note"
applies_to: "[dossier-domaine]/*.md"
required:
- description
- sujets
optional:
- [champs spécifiques au domaine basés sur les signaux de la conversation]
enums:
[champ]:
- [valeurs pertinentes pour le domaine]
3d. Vérification des collisions
Ceci est crucial pour la composition multi-domaine. Vérifiez :
-
Unicité des noms de fichier -- les titres des notes du nouveau domaine n'entreront pas en collision avec les notes existantes. Les liens wiki se résolvent par nom de fichier sur l'ensemble de l'espace de travail, donc chaque nom de fichier doit être unique.
-
Noms des champs de schéma -- les champs du nouveau domaine n'entrent pas en conflit avec les champs des domaines existants. Si les deux domaines utilisent un nom de champ (par exemple,
type), les valeurs d'énumération doivent être mutuellement exclusives ou le champ doit avoir une sémantique compatible. -
Noms des modèles -- les modèles du nouveau domaine ont des noms distincts des modèles existants.
-
Noms des dossiers -- les dossiers du nouveau domaine n'entrent pas en collision avec les dossiers existants.
Si des collisions sont détectées, résolvez-les avant de continuer.
PHASE 4 : Vérifier les règles de composition
Lisez ${CLAUDE_PLUGIN_ROOT}/reference/derivation-validation.md (Test 4 : Composition multi-domaine) pour le modèle de composition validé.
Vérifiez chaque règle de composition :
Règle 1 : Les liens wiki se résolvent sans ambiguïté dans l'espace de noms partagé
Tous les noms de fichiers de notes doivent être uniques dans tous les domaines. Les conventions de nommage du nouveau domaine doivent être compatibles avec celles existantes.
Règle 2 : Le hub MOC lie tous les MOC de domaine
Le hub MOC existant (index.md ou équivalent) doit être mis à jour pour inclure le point d'entrée du nouveau domaine. La hiérarchie devient :
hub -> MOC des domaines existants
-> nouveau domaine MOC
Règle 3 : La réflexion inter-domaines recherche dans tous les dossiers de notes
Si la recherche de connexion (réflexion) est active, elle doit rechercher dans tous les domaines — une note du nouveau domaine pourrait se connecter à une note du domaine existant. Les collections de recherche sémantique doivent inclure le dossier du nouveau domaine.
Règle 4 : Le traitement spécifique au domaine peut coexister
Si le nouveau domaine nécessite une intensité de traitement différente du domaine existant, le pipeline doit acheminer par type de note. Traitement lourd pour les notes de recherche, traitement léger pour les notes de relations, etc.
Règle 5 : Le chargement des fichiers de contexte est progressif
Le guide méthodologique du nouveau domaine doit se charger uniquement lorsqu'on travaille dans ce domaine, pas à chaque démarrage de session. Cela évite le gonflement du contexte à mesure que les domaines s'accumulent.
Vérification de cohérence
Exécutez la configuration du nouveau domaine via ${CLAUDE_PLUGIN_ROOT}/reference/interaction-constraints.md :
- Violations de contraintes dures entre la configuration du nouveau domaine et les dimensions de niveau système
- Avertissements de contraintes souples spécifiques au nouveau domaine
- Effets en cascade sur le(s) domaine(s) existant(s)
PHASE 5 : Présenter la proposition
Montrez à l'utilisateur exactement ce qui sera créé et comment cela se connecte à ce qui existe.
Format de sortie :
=== PROPOSITION D'AJOUT DE DOMAINE ===
Nouveau domaine : [nom du domaine]
Vocabulaire : [mappages de termes clés]
--- Ce qui sera créé ---
Structure de dossiers :
[dossier-domaine]/ <- [description]
index.md <- hub MOC du domaine
[boîte-réception-domaine]/ <- zone de capture (si traitement >= modéré)
modèles/[domaine]-note.md <- modèle de note avec le schéma du domaine
--- Connexions au système existant ---
- Hub MOC (index.md) : ajouter la section [nouveau domaine] avec un lien vers [[domaine-index]]
- Liens inter-domaines : les notes [nouveau domaine] peuvent lier les notes [domaine existant] et vice versa
- Infrastructure partagée : self/, ops/, templates/ restent partagés
- Recherche sémantique : [nouvelle collection ajoutée / non nécessaire au volume actuel]
--- Ce qui ne change PAS ---
- Dossier [domaine existant] : intact
- Modèles existants : intacts
- Hiérarchie MOC existante : intacte (le hub gagne un nouveau lien)
- Espace self/ : partagé (methodology.md mis à jour avec les modèles multi-domaines)
- Espace ops/ : partagé (derivation.md mis à jour avec l'ajout du domaine)
--- Configuration du domaine ---
| Dimension | Position | Justification |
|-----------|----------|---------------|
| Granularité | [val] | [raison] |
| Traitement | [val] | [raison] |
| Maintenance | [val] | [raison] |
| Schéma | [val] | [raison] |
| Liaison | [val] | [raison] |
| (dimensions de niveau système héritées du système existant) |
--- Aperçu du schéma ---
[Afficher le bloc _schema pour le modèle du nouveau domaine]
--- Mappage du vocabulaire ---
| Universel | Nouveau domaine | Domaine existant |
|-----------|----------------|------------------|
| note | [terme] | [terme existant] |
| ... | ... | ... |
Voulez-vous que je crée cela ? Je peux ajuster n'importe quoi avant de générer.
=== FIN DE LA PROPOSITION ===
Attendez l'approbation de l'utilisateur avant de continuer.
PHASE 6 : Générer
Créez l'infrastructure du nouveau domaine. L'ordre compte — les artefacts ultérieurs référencent les précédents.
Étape 1 : Structure de dossiers du domaine
Créez le dossier de notes du domaine et le dossier de boîte de réception optionnel :
mkdir -p [dossier-domaine]
mkdir -p [boîte-réception-domaine] # si traitement >= modéré
Étape 2 : Modèle de note du domaine
Créez modèles/[domaine]-note.md avec le bloc _schema dérivé, les champs obligatoires et facultatifs, et le vocabulaire du domaine dans les commentaires et exemples.
Étape 3 : Hub MOC du domaine
Créez [dossier-domaine]/index.md :
---
description: [description du point d'entrée dans le vocabulaire du domaine]
type: moc
---
# index
[Paragraphe d'orientation dans le vocabulaire du domaine]
## [domaine:Sujets]
(les sujets émergeront à mesure que les notes s'accumulent)
## Pour commencer
1. Capturez votre première [domaine:note]
2. Connectez-la à ce hub
Étape 4 : Guide du domaine
Créez un document de méthodologie spécifique au domaine qui se charge lorsque vous travaillez dans ce domaine. Pour Claude Code : .claude/skills/[domaine]-guide/SKILL.md ou une section dans le fichier de contexte. Pour d'autres plateformes : un fichier de guide autonome.
Le guide couvre :
- Comment capturer dans ce domaine
- Comment traiter (à l'intensité dérivée)
- Quand connecter entre domaines
- Normes de qualité spécifiques au domaine
- Référence du vocabulaire du domaine
Étape 5 : Mettre à jour le hub MOC
Ajoutez le nouveau domaine au hub MOC existant (index.md) :
## [Nom du nouveau domaine]
- [[domaine-index]] -- [description de ce que ce domaine suit]
Étape 6 : Mettre à jour le fichier de contexte
Ajoutez au fichier de contexte :
- Routage du domaine : lorsque vous travaillez dans [domaine], charger [guide du domaine]
- Vocabulaire : termes du nouveau domaine ajoutés à la référence du vocabulaire
- Traitement : si l'intensité du traitement est différente, documenter le routage
- Liens inter-domaines : quand et comment connecter entre domaines
Étape 7 : Mettre à jour self/methodology.md
Ajoutez des modèles de travail multi-domaines :
- Comment basculer entre les domaines
- Quand créer des connexions inter-domaines
- Déclencheurs de traitement par domaine
Étape 8 : Mettre à jour ops/derivation.md
Documentez l'ajout du domaine :
- Nom et vocabulaire du nouveau domaine
- Positions des dimensions ajustables par domaine avec justification
- Règles de composition vérifiées
- Modèles de connexion inter-domaines
- Date et contexte de l'ajout
Étape 9 : Mettre à jour la recherche sémantique (si configurée)
Si qmd ou équivalent est configuré :
# Ajouter une nouvelle collection pour le dossier du domaine
qmd update
qmd embed
Mettez à jour .mcp.json ou la configuration équivalente pour inclure la nouvelle collection.
Étape 10 : Compétences de traitement du domaine (si traitement >= modéré)
Si le nouveau domaine a besoin de ses propres compétences de traitement (parce que l'intensité du traitement ou le vocabulaire diffère du domaine existant), générez des versions adaptées au domaine des compétences réduire/réfléchir/vérifier.
Si les compétences existantes peuvent gérer le routage multi-domaines par type de note, mettez-les à jour au lieu de créer des doublons.
PHASE 7 : Valider
Vérifications du noyau pour les nouveaux fichiers du domaine
Exécutez la validation du noyau contre les nouveaux fichiers du domaine :
- Frontmatter YAML valide sur tous les nouveaux fichiers
- Les liens wiki des nouveaux fichiers se résolvent (y compris les liens inter-domaines)
- Le nouveau MOC du domaine est accessible depuis le hub
- Les champs de description sont présents
- Les pieds de page des sujets référencent le MOC du domaine
Validation de la composition
- Aucun conflit de champ -- grep tous les modèles pour les noms de champ, vérifiez qu'il n'y a pas de conflits sémantiques
- Accessibilité du hub -- le hub MOC lie tous les MOC de domaine, tous les MOC de domaine lient leurs notes
- Test de lien inter-domaines -- créez un lien de test du nouveau domaine vers le domaine existant, vérifiez qu'il se résout
- Unicité des noms de fichier -- vérifiez qu'il n'y a pas de noms de fichier en double dans tous les domaines :
...find . -name ...
...