atlasray66-collab/dlm-load

Charge le contexte minimum suffisant depuis un doc_llm appartenant au dépôt avant la planification, l'implémentation, la revue ou le débogage. À utiliser lorsque l'utilisateur nomme un Epic/Sous-tâche, demande à initialiser le contexte, ou que le dépôt actif utilise déjà DLM.

Qu'est-ce que dlm-load ?

Cette compétence (`dlm-load`) est conçue pour charger le contexte minimal suffisant depuis un `doc_llm` détenu par le dépôt avant de démarrer des activités comme la planification, l'implémentation, la revue ou le débogage. Elle garantit que l'agent AI utilise uniquement les informations appartenant au dépôt spécifié, évitant les contaminations de contexte entre projets. La compétence résout d'abord le dépôt cible (en préférant la racine explicitement fournie ou la racine Git la plus proche contenant un `doc_llm`), puis vérifie l'identité via `AGENTS.md`, `dlm.json` et `README.md`. Elle prend en charge deux modes d'intention : `load-only` (lecture seule pour inspection) et `load-and-continue` (chargement suivi de l'exécution de la tâche sans confirmation redondante). La compétence applique également une gouvernance basée sur les résultats via le fichier partagé `outcome-governance.md`, garantissant que le chargement n'accorde pas d'autorité de mutation et que les décisions matérielles sont fondées sur des preuves et des contraintes à jour. Elle est portable et peut être utilisée avec des agents comme Claude Code ou d'autres outils compatibles DLM.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/atlasray66-collab/agent-dlm-skills/tree/main/skills/dlm-load

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

DLM Load 7 Portable

Objectif

Verrouiller un dépôt et charger son propre contrat, contraintes, tâche active, fichiers manifestes et ancres source. Cette compétence personnelle définit la méthode de chargement ; l'état du dépôt reste entièrement la propriété du dépôt.

Porte de gouvernance des résultats

Appliquer la Gouvernance des résultats DLM partagée. Lisez-la avant load-and-continue, avant de traiter un manque de contexte comme bloquant, ou chaque fois que le chargement alimente une revue formelle, une délégation, une publication ou une autre décision d'état externe.

  • Traiter le chargement comme une vérification combinée d'identité/de sécurité de périmètre suivie des faits minimaux nécessaires à la prochaine décision matérielle.
  • Ne pas répéter l'initialisation de session, regeler l'autorité ou générer des artefacts de plan de contrôle lorsque l'identité du dépôt/de la tâche est déjà stable.
  • load-and-continue ne contourne pas la gouvernance : avant la première écriture substantielle, la délégation exécutable, l'action externe ou la mutation d'état/ressource, confirmer que la Baseline d'Acceptation applicable est Gelée par son propriétaire ou qu'une autorisation de session explicite équivalente fournit la même cible, les mêmes critères, le Périmètre Autorisé, les preuves et la ligne d'arrêt.
  • Un manque de contexte bloque uniquement lorsqu'un contrat applicable le marque comme requis et que son absence empêche matériellement la revendication ou l'action sûre en cours. La vétusté administrative non liée est signalée pour clôture pilotée par le consommateur, sans retarder le travail cible.
  • La documentation, le code source, les preuves d'exécution et l'état de coordination restent séparés ; charger la couche qui correspond à la décision au lieu d'en utiliser une comme proxy pour une autre.

Résolution du dépôt

  1. Préférer une racine de dépôt explicitement fournie par l'utilisateur.
  2. Sinon, utiliser la racine Git la plus proche contenant le doc_llm pertinent.
  3. En cas d'ambiguïté dans un monorepo ou un checkout imbriqué, inspecter les identités candidates doc_llm/dlm.json et ne demander que si la cible ne peut toujours pas être déterminée en toute sécurité.
  4. Lire les fichiers AGENTS.md, doc_llm/dlm.json et doc_llm/README.md applicables avant d'interpréter les chemins ou les statuts.
  5. Ne jamais charger le DLM d'un projet voisin parce qu'il est familier de mémoire ou d'une conversation précédente.

Si le projet a un contrat, le repository_root, doc_llm_root, project_id, les statuts et les règles de compatibilité déclarés sont faisant autorité. Les chemins des compétences personnelles ne sont jamais des fichiers de contexte de projet.

Modes d'intention

  • load-only : l'utilisateur a seulement demandé à inspecter, résumer ou évaluer le contexte. Rester en lecture seule et s'arrêter après le rapport de contexte.
  • load-and-continue : l'utilisateur a déjà demandé une planification, une implémentation, une revue ou un diagnostic. Charger d'abord, puis continuer la tâche autorisée sans demander une confirmation redondante.

Le chargement est une phase de flux de travail, pas un mode de plateforme et pas une autorité de mutation.

Initialisation de session

À la première entrée, lire le contrat/README et les contraintes BRIEF/L0 applicables ; les réutiliser tant que l'identité du dépôt et les contraintes pertinentes restent stables. Pour une tâche nommée ou déjà verrouillée, aller directement à son Epic/Sous-tâche et aux entrées de manifeste requises. Lire le backlog/index uniquement pour découvrir la propriété, résoudre les dépendances ou choisir un travail dans une file d'attente déjà autorisée. Un diagnostic ou une question ad hoc n'autorise pas la sélection ou l'exécution d'un élément de backlog non lié.

Lorsque la sélection de tâche fait partie de la demande de l'utilisateur ou d'une file d'attente déjà autorisée, sélectionner de manière déterministe :

  1. Epic/Sous-tâche spécifié par l'utilisateur ;
  2. tâche déjà verrouillée dans la conversation en cours et toujours active ;
  3. tâche en cours ordonnée par les règles de backlog/priorité/ID du dépôt ;
  4. tâche planifiée prête pour les dépendances utilisant le même ordre ;
  5. les tâches bloquées sont signalées avec leur condition de déblocage, non traitées comme exécutables.

Si les candidats restent à égalité après application des règles du dépôt, montrer le plus petit ensemble de candidats utile au lieu de deviner par horodatage de fichier ou de lire chaque tâche historique.

Identité courante et reprise

  • Lorsque le projet fourni par l'utilisateur n'a pas de métadonnées Git, verrouiller son répertoire explicite plus son propre contrat DLM. Signaler l'état Git comme indisponible ; ne jamais adopter un dépôt parent ou voisin pour fabriquer une identité.
  • Utiliser Epic/Sous-tâche comme identité de tâche canonique. Résoudre d'abord une ancienne dépendance courte dans son Epic propriétaire, puis uniquement si elle est globalement unique. Un ID nu partagé par plusieurs Epics nécessite une désambiguïsation ; il ne doit pas sélectionner silencieusement la première correspondance.
  • La table Meta actuelle de tête (ou une section ## Meta explicite) est faisant autorité. Les journaux historiques, les plans archivés et une entrée Gelée ancienne ne remplacent pas le statut ou l'acceptation actuelle. Lire les preuves historiques uniquement lorsque la prochaine décision en a besoin.
  • Préférer une commande next / context existante appartenant au dépôt lorsqu'elle fournit l'identité, les dépendances, les bloqueurs et l'ordre de lecture. Ne pas installer une nouvelle commande simplement pour charger le contexte ni traiter sa sortie comme une autorité de mutation.

Exploration approfondie de la tâche

  1. Lire la tâche et localiser <context_manifest>.
  2. Pour le schéma 2, exiger un project correspondant, des chemins / relatifs au dépôt et un fichier concret par entrée.
  3. Chaque <file> a path, intent et required ; section et defer sont facultatifs.
  4. Rejeter les chemins absolus, .., les répertoires, les dépôts frères, les racines de compétences personnelles et les fichiers de flux de travail .agents/skills comme contexte de tâche.
  5. Les fichiers manquants requis par le contrat de tâche actuel bloquent l'exploration/revendication approfondie affectée. Les fichiers facultatifs manquants, ou les enregistrements administratifs non liés sans consommateur actuel, deviennent des avertissements.
  6. defer="true" n'est valide qu'avec required="false" ; ne le charger que lorsque la décision actuelle en a besoin.
  7. Lire les fichiers indépendants en parallèle lorsque c'est utile. Respecter section en chargeant précisément la section pertinente.

Pour les manifestes hérités, suivre la règle de compatibilité du dépôt et signaler l'écart. Ne pas migrer silencieusement pendant le chargement.

Contexte axé sur les décisions et reprise

Après les entrées requises, organiser les lectures supplémentaires autour de la prochaine question matérielle : contraintes applicables, preuves et contre-preuves, faits manquants et la prochaine entrée source. La pertinence seule n'établit pas la suffisance. Lors d'une reprise réelle, conserver la dernière preuve applicable et les voies échouées exclues ; rafraîchir les dépendances modifiées au lieu de répéter l'initialisation de session.

Pour la réutilisation des preuves, le changement de connaissances L2 ou l'échec répété, lire la section pertinente de Preuves et décisions. Pour un ensemble utile de modifications explicitement identifiées, scripts/dlm_impact.py --repo-root <repo> --changed-file <fichier-relatif-au-dépôt> --json peut renvoyer des candidats à la revue L2 en lecture seule, y compris la propagation facultative de depends_on. Il ne certifie pas la validité des connaissances ni ne remplace les entrées de manifeste requises. Ne pas l'exécuter pour chaque lecture de routine.

Ancrage source

  • Utiliser rg, la navigation par symbole, les fichiers du projet, les tests, les journaux et les preuves générées pour localiser la vérité d'implémentation.
  • Commencer par des lectures source étroites. Lire les fichiers complets lorsque le cycle de vie, la sérialisation, la machine d'état ou le comportement inter-membres rend les extraits locaux non sécurisés.
  • Distinguer les affirmations de documentation, les faits source, les preuves d'exécution et les inférences non résolues.
  • Si DLM et la source sont en désaccord, signaler l'inadéquation et continuer à partir de la source/des preuves actuelles, sauf si la tâche est explicitement prioritaire sur la documentation.

Chargement ad hoc

Pendant l'exécution, acheminer via le L1 global/L1 de domaine vers le plus petit L2 pertinent et les ancres source. Ne pas répéter toute l'initialisation de session lorsqu'une seule décision de domaine a besoin de plus de contexte.

Validation et sortie

Exécuter la vérification de santé du dépôt lorsque l'intégrité du contrat/du manifeste est importante pour la prochaine décision ou que l'utilisateur a demandé une validation DLM. Utiliser le docteur générique comme preuve de contrat de support, pas comme un rituel :

python -B -X utf8 <skill-dir>/scripts/dlm_doctor.py --repo-root <repo> --require-contract

Classer les échecs par rapport à la cible et au contrat actuels. Un échec de contrat/chemin pertinent peut bloquer l'action DLM affectée ; un avertissement non lié préexistant ou administratif ne peut pas invalider un contexte technique par ailleurs suffisant.

Signaler l'identité du dépôt/projet, la tâche sélectionnée et sa base de sélection, les contraintes et ancres source chargées, le contexte manquant ou obsolète, l'impact matériel de tout blocage, et si la tâche originale va maintenant continuer. Une fois que la prochaine décision dispose d'un contexte suffisant, arrêter le chargement et rediriger l'effort vers ce travail.

Résumé facultatif du registre v2 (scripts/dlm.py brief)

Lors du chargement d'un Epic qui utilise ledger.json, exécuter python -X utf8 <skill-dir>/scripts/dlm.py brief <E> <S> (ou dlm.py status) pour restituer le résumé de la tâche, les obligations actives, les hypothèses non résolues et l'état du point de contrôle précédent avec dlm_impact.py.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Skills associés