Vault Crystallize

Que fait Vault Crystallize ?

Cette compétence est l'autorité comportementale pour crystallize et distill dans un coffre de connaissances. Les protocoles du coffre sont des contrats de données :

• AGENTS.md définit les limites de l'espace de travail, les niveaux de démarrage et la propriété d'écriture.
• global/agent-rules/handoff-protocol.md définit le format Handoff.md.
• global/agent-rules/llm-wiki-protocol.md définit le schéma des pages llm-wiki/, les preuves, les contradictions, l'intégration et les vérifications de santé.
• global/agent-rules/llm-wiki-format.md définit les modèles de page lorsqu'ils sont présents.

Ne cherchez pas de section ## Crystallize dans le protocole. Si une telle section existe dans un ancien coffre, préférez cette compétence pour le comportement et utilisez le protocole uniquement pour les contrats de données.

Limite

Déclencheurs dédiés :

• 结晶, 结晶一下, crystallize -> sauvegarder l'état de récupération et les connaissances stables à long terme uniquement si elles ont changé.
• 蒸馏, distill -> transformer une source concrète en entrées de preuves citées avec niveau de confiance.

N'utilisez pas cette compétence pour neat-freak, des audits approfondis, un nettoyage général de la documentation, une synchronisation mémoire, ou un résumé "结晶版" raffiné sauf si l'utilisateur le demande explicitement comme tâche séparée. Un simple 收尾, "wrap up", "整理一下", ou "sync my notes" ne sont pas des déclencheurs de crystallize.

Les agents qui n'ont pas installé cette compétence relèvent d'un problème d'installation/mise à jour, pas d'une raison pour dupliquer le comportement crystallize dans les protocoles du coffre. Ne créez pas de répertoires .claude/skills, .agents/skills, de jonctions ou de chemins d'installation par agent sauf si l'utilisateur demande explicitement un travail d'installation.

Les wrappers de commandes natifs se trouvent dans commands/ et commands/<agent>/. Les compétences d'alias ordinaires partagées se trouvent sous skills/ ; n'ajoutez pas de fichiers SKILL.md d'alias en double sous des répertoires spécifiques à une plateforme, car Codex pourrait les découvrir récursivement deux fois. Traitez-les tous comme des adaptateurs d'invocation explicite ; conservez SKILL.md comme autorité comportementale lors de leur mise à jour.

Langue par défaut

Rédigez le contenu de Handoff.md et llm-wiki/ en chinois par défaut. Conservez les identifiants techniques stables en anglais, y compris le code, les commandes, les noms de variables, les chemins, les noms d'API, les noms de paquets et les titres de sources lorsque la préservation du titre original est importante.

Utilisez une autre langue uniquement lorsque l'utilisateur le demande explicitement, lorsque vous citez du matériel source, ou lorsqu'une règle de projet existante est plus spécifique pour cette unité.

Commande : crystallize

1. Identifiez l'unité actuelle :
   • Travail sous projects/<name>/ -> ce projet.
   • Travail sous research/<name>/ -> ce domaine de recherche, sauf si un sous-module a son propre Handoff.md.
   • Gouvernance du coffre ou règles inter-coffres -> Handoff.md racine et global/llm-wiki/.
2. Lisez le Handoff.md de l'unité actuelle avant de décrire l'état actuel du projet. Si l'unité n'est pas claire, lisez le Handoff.md racine comme index des projets actifs ; si toujours pas clair, posez une question concise.
3. Décidez si quelque chose a réellement changé :
   • Point de récupération modifié -> mettez à jour le Handoff.md de l'unité actuelle.
   • Conclusion stable qu'un autre fil de discussion devrait connaître à long terme -> mettez à jour la page llm-wiki/ existante correspondante.
   • Aucun changement de récupération ou à long terme -> n'écrivez rien et expliquez pourquoi.
4. Acheminez chaque conclusion stable en fonction de la portée de réutilisation avant d'écrire :
   • Demandez : cette conclusion resterait-elle vraie et utile dans un autre projet effectuant une tâche similaire demain ? Oui -> écrivez le fait général dans la page global/llm-wiki/<topic>.md correspondante et ne conservez dans le wiki du projet que les détails d'application spécifiques au projet ainsi qu'un pointeur wikilink. Incertain -> conservez-le au niveau du projet (par défaut, descendez).
   • Règle des deux : si cette session a utilisé ou réécrit une conclusion qui se trouve dans le wiki d'un autre projet, promouvez-la maintenant vers une page de sujet global.
   • Lire avant d'écrire : lisez d'abord la page sujet cible et fusionnez-la dans une entrée existante portant sur le même sujet ; n'ajoutez jamais à l'aveugle. Créez une nouvelle page sujet uniquement si aucun sujet existant ne convient, et mettez à jour ## Triggers dans global/llm-wiki/index.md lors du même passage.
5. N'écrivez que la couche appropriée :
   • Handoff.md reçoit le statut actuel, les fichiers actifs, les questions ouvertes, les prochaines actions et le contexte de reprise.
   • llm-wiki/ reçoit les décisions stables, méthodes, pièges, mémoire, entités/concepts ou preuves.
   • log.md est réservé aux opérations de connaissance vraiment majeures, pas à crystallize de routine.
   • La mémoire privée d'outil, la relecture de processus et les caches d'agent ne deviennent jamais une autorité du coffre.
6. Si Handoff.md contient ## Tracks, parcourez tous les fils actifs avant de finaliser. Préservez les fils non focalisés sauf si le travail les a explicitement fermés.
7. Exécutez la liste de vérification ci-dessous avant de signaler l'achèvement.

Commande : distill

À utiliser uniquement lorsque l'utilisateur dit explicitement distill, 蒸馏, ou demande de transformer une source concrète en preuve tracée.

Entrées :

• Source : un chemin de fichier, du texte collé, le contenu d'une URL récupérée, une note, un PDF ou un extrait de conversation.
• Unité cible : déduite du chemin source ou de la tâche actuelle ; si ambiguë, posez une question concise.
• Destination : llm-wiki/evidence-log.md de l'unité cible.

Flux de travail :

1. Lisez le Handoff.md de l'unité cible.
2. Lisez les sections ## Evidence Log et ## Pending Contradictions du fichier global/agent-rules/llm-wiki-protocol.md.
3. Divisez la source en blocs numérotés B1, B2, B3, ... dans l'ordre source. Conservez les sources brutes longues dans sources/ ou notes/ ; placez uniquement les pointeurs et les preuves concises dans llm-wiki/.
4. Séparez les preuves des inférences. Les affirmations de preuve citent (src: Bn). Les inférences nomment les blocs source dont elles dépendent.
5. Attribuez un niveau de confiance par conclusion : high, medium, low ou unverified.
6. Si de nouvelles preuves contredisent un llm-wiki/ existant, suivez ## Pending Contradictions ; ne réécrivez pas en silence.

Forme d'une entrée de preuve :

### YYYY-MM-DD · <titre de la source>
- **来源：** [[relative/source-or-note]]
- **原文块：**
  - B1: <localisateur source court ou résumé d'extrait>
  - B2: <localisateur source court ou résumé d'extrait>
- **证据结论：**
  - <affirmation> (src: B1) - confiance: <high|medium|low|unverified>
- **推断：**
  - <inférence> (de: B1+B2) - confiance: <high|medium|low|unverified>
- **待验证：** <besoin de vérification spécifique, ou `无`>

Liste de vérification

Vérification de Handoff :

• Exactement les sections requises par handoff-protocol.md ; ## Tracks est optionnel et uniquement pour les fils parallèles actifs.
• Si ## Tracks existe, exactement un fil a [focus].
• ## Last Done a au plus 4 entrées, en ordre chronologique inverse, chacune se terminant par une date.
• ## Next Actions a au plus 3 éléments de case à cocher concrets.
• ## Active Files explique pourquoi chaque fichier est actif maintenant, pas ce qu'est le fichier.
• ## Decisions contient un wikilink vers [[llm-wiki/decisions]] ou un ID de bloc de décision, ou indique None.
• ## Resume indique au prochain agent quoi lire et quel modèle mental conserver.

Vérification du wiki LLM :

• Les pages nouvelles ou considérablement modifiées ont un en-tête (frontmatter) requis par llm-wiki-protocol.md.
• Le type de page correspond au contenu : décision, méthode, piège, mémoire, preuve, entité, concept, glossaire ou journal d'opérations.
• Les nouvelles pages sont liées depuis le llm-wiki/index.md local.
• Les affirmations ont un niveau de confiance ; les affirmations de preuve pointent vers des sources.
• Les contradictions non résolues sont enregistrées à l'endroit désigné au lieu d'être cachées.
• Les conclusions réutilisables entre projets sont acheminées vers les pages de sujet global/llm-wiki/ ; aucun fait n'est dupliqué entre les couches (le projet conserve les détails d'application plus un pointeur).
• Les en-têtes d'entrée et les ensembles de champs correspondent au modèle llm-wiki-format.md pour le type de page : les pages d'affirmation (méthode / piège / sujet) sont indexées par nom de sujet stable, les pages d'événement (décisions / preuves / journal) par date.
• Aucun wikilink aliasé n'apparaît dans les tableaux Markdown.

Vérification comportementale :

• N'exécutez ni n'invoquez neat-freak sauf demande explicite.
• N'élargissez pas la tâche au nettoyage de documentation, à la synchronisation mémoire ou au remaniement de formatage.
• Ne gérez pas l'installation de compétences locales d'agent sauf demande explicite.
• N'écrivez pas si rien n'a changé ; signaler "rien n'a changé" est un résultat valide.

Validation

Lorsque des fichiers ont été créés, déplacés, renommés, ou que l'utilisateur change de fil/agent, exécutez la suite de vérification en lecture seule depuis la racine du coffre :

pwsh -NoProfile -File global/tools/vault-health.ps1
pwsh -NoProfile -File global/tools/vault-meta.ps1 -Audit
pwsh -NoProfile -File global/tools/vault-links.ps1

Pour les modifications de contenu uniquement, exécutez la vérification pertinente la plus petite et signalez ce qui a été ignoré.

Modes de défaillance courants

Échec	Correction
"Les autres agents sans la compétence ne cristalliseront pas."	L'installation/mise à jour de la distribution résout cela. Ne dupliquez pas le comportement dans les protocoles.
Lit llm-wiki-protocol.md ## Crystallize.	Arrêtez ; cette compétence possède le comportement crystallize. Les protocoles définissent uniquement les formats et les vérifications de santé.
Traite 收尾 ou "nettoyer la doc" comme un crystallize.	Ne déclenchez pas sauf si des mots dédiés ou une intention de preuve explicite apparaissent.
Écrit des journaux de processus dans llm-wiki/.	Seules les conclusions stables y ont leur place.
Ajoute à des listes Handoff obsolètes.	Réécrivez les fenêtres glissantes dans les limites documentées.
Ajoute une nouvelle entrée datée à une page d'affirmation (méthodes / pièges / sujet) au lieu de fusionner.	Les pages d'affirmation sont indexées par sujet : localisez l'entrée existante, réécrivez-la sur place, mettez à jour updated / 验证于.