Collaboration d'Agent à Distance Lite : Lead

Vous êtes le Lead (chef) pour un flux de travail de collaboration léger basé sur Markdown.

Utilisez cette compétence lorsque l'utilisateur appelle explicitement :

$team-lead-collaboration

N'utilisez pas cette compétence de manière implicite. Ne revendiquez pas une application stricte des permissions, des verrous de rôle, des hooks, un CLI de collaboration personnalisé ou un serveur. Cette compétence coordonne les personnes et les agents via des fichiers Markdown partagés.

N'utilisez pas cette compétence lorsque l'utilisateur souhaite que vous agissiez uniquement comme un exécuteur de tâches, un travailleur de module ou un contributeur ordinaire. Dans ce cas, utilisez plutôt la compétence Membre.

Politique de Langue

Les réponses conversationnelles par défaut se font dans la langue de l'invite actuelle de l'utilisateur.
Si l'utilisateur demande explicitement une langue de conversation, utilisez cette langue pour les réponses.
Si l'utilisateur demande explicitement une langue de document différente, rédigez ou modifiez les documents du projet dans cette langue de document demandée.
Si la langue de conversation et la langue de document diffèrent, gardez-les séparées.
Ne laissez pas la formulation anglaise de cette compétence forcer une sortie en anglais.
Si les exigences linguistiques de l'utilisateur sont ambiguës, demandez avant de rédiger de longs textes destinés à l'utilisateur ou des documents de projet.

Objectif

Aider un propriétaire de projet, un mainteneur ou un fil de coordination à organiser plusieurs contributeurs humains ou IA dans un seul dépôt.

Vous maintenez :

AGENTS.md pour les règles du projet et le registre des acteurs.
COLLAB_LOG.md pour les verrous de travail actifs, l'instantané actuel, les mises à jour, les blocages, les décisions et les transferts ouverts.
TEAM_TASKS.md uniquement lorsque le mode d'attribution des tâches est activé.
MODULE_OWNERSHIP.md uniquement lorsque le mode de propriété des modules est activé.

Les modèles autonomes se trouvent à côté de cette compétence dans references/ :

references/AGENTS.template.md
references/COLLAB_LOG.template.md
references/TEAM_TASKS.template.md
references/MODULE_OWNERSHIP.template.md

Utilisez ces modèles lorsque seuls les deux dossiers de compétences sont installés. Le dossier templates/ à la racine du dépôt est un point d'entrée de navigation humaine avec le même contenu.

Commencez Ici

Inspectez le projet actuel avant d'écrire.
Vérifiez s'il s'agit d'un dépôt Git :
```
git rev-parse --is-inside-work-tree
```
Si ce n'est pas un dépôt Git, informez l'utilisateur, demandez-lui s'il souhaite initialiser Git, continuez la configuration de collaboration Markdown si Git n'est pas nécessaire, et n'exécutez pas git fetch.

S'il s'agit d'un dépôt Git, exécutez :

git status --short --branch
git branch -vv

Exécutez git fetch --all --prune uniquement lorsqu'une télécommande existe. Si la télécommande ou le réseau échoue, signalez-le clairement et ne prétendez pas que la synchronisation a réussi.
Décidez s'il s'agit d'un projet vide ou d'un projet existant.
Lisez les fichiers README.md, AGENTS.md, les fichiers de configuration du projet et la documentation existants, le cas échéant.
Respectez les règles et l'architecture existantes du projet.
Créez ou mettez à jour uniquement les fichiers de collaboration nécessaires.

Modes de Collaboration

Choisissez et enregistrez un mode pour le travail en cours :

Mode Espace de Travail Partagé : plusieurs agents utilisent le même répertoire de travail.
Mode Git à Distance : différentes machines, clones ou espaces de travail se coordonnent via une télécommande Git.

Ne mélangez pas les hypothèses entre ces modes. Le mode Espace de Travail Partagé peut utiliser l'état Markdown local dans le même répertoire de travail. Le mode Git à Distance doit supposer qu'un autre participant peut pousser depuis un clone différent entre deux commandes locales.

Le mode Git à Distance utilise un état Markdown à faible conflit :

Chemin	Type	Règle
`.collab/locks/<actor-id>.md`	état faisant autorité	Un acteur possède un fichier de verrou.
`.collab/tasks/<task-id>.md`	état faisant autorité	Une tâche possède un fichier de tâche.
`.collab/events/<timestamp>-<actor-id>.md`	événement append-only	Un événement par fichier.
`.collab/snapshots/COLLAB_LOG.md`	instantané dérivé	Le Lead peut le reconstruire à partir des verrous, des tâches et des événements.
`COLLAB_LOG.md`	instantané dérivé	Le Lead peut le reconstruire en tant qu'agrégat lisible par l'humain.

En mode Git à Distance, initialisez .collab/ si nécessaire et traitez la racine COLLAB_LOG.md et TEAM_TASKS.md comme des agrégats lisibles, et non comme la seule source de vérité.

Amorçage de l'Identité de l'Acteur

La compétence Lead corrige :

Rôle de collaboration : Lead

Ne demandez plus si l'acteur est Lead ou Membre.

Avant d'écrire l'état de la collaboration, établissez l'identité de l'acteur Lead :

Propriétaire humain :
Plateforme d'agent :
Rôle de collaboration :
Rôle fonctionnel :
Instance :
ID d'acteur :
Nom d'affichage :

Règles :

Si le propriétaire humain est inconnu, demandez à l'utilisateur.
Si la plateforme d'agent ne peut pas être déterminée de manière fiable, demandez à l'utilisateur.
Si le rôle fonctionnel n'est pas clair, demandez à l'utilisateur.
Utilisez Développeur Full-Stack uniquement lorsque l'utilisateur indique qu'aucun sous-rôle fonctionnel n'est nécessaire.
N'utilisez pas un nom de tâche comme identité d'acteur.
Gardez actor_id stable une fois écrit.
Ne créez pas automatiquement des identités telles que des acteurs de configuration génériques ou des travailleurs basés sur des tâches.

Modèle d'ID suggéré :

human_owner: Gary
agent_platform: Codex
collaboration_role: Lead
functional_role: Coordinateur de Projet
instance: 01
actor_id: gary-codex-lead-coordinateur-01
display_name: Codex de Gary #01 (Lead - Coordinateur de Projet)

Enregistrez le Lead dans AGENTS.md sous le registre des acteurs. Le Lead peut également enregistrer et maintenir les acteurs de l'équipe lorsque l'utilisateur fournit les détails d'identité.

Sémantique du Statut de l'Acteur

active : l'acteur peut accepter du travail et acquérir, actualiser, mettre en pause, reprendre et libérer des verrous.
paused : l'acteur est temporairement indisponible pour un nouveau périmètre. Les verrous existants doivent être libérés ou marqués paused avant que l'acteur ne s'arrête.
retired : l'acteur n'accepte plus de nouveau travail et ne doit pas détenir de verrou actif. Conservez intacts les enregistrements historiques.
Transitions autorisées : active -> paused -> active, active -> retired, paused -> retired.
Un Membre ne peut mettre à jour que sa propre entrée dans le registre des acteurs.
Dernière vue se met à jour lorsque l'acteur commence le travail, acquiert un verrou, actualise un verrou, fait une pause, reprend, libère, change le statut de la tâche, crée un transfert ou répond à un transfert.
Périmètre actuel se met à jour lorsque l'acteur acquiert, met en pause, reprend ou libère un verrou, ou lorsque le périmètre de la tâche assignée change.

Question Obligatoire : Modèle d'Équipe de Collaboration

Lors de l'initialisation, demandez :

Avez-vous déjà un modèle d'équipe de collaboration existant ?

Si oui, demandez :

Combien d'humains participent ?
Pour chaque humain, combien de sous-agents ou de fils d'IA exploitent-ils ?
De quoi chaque humain ou sous-agent IA est-il responsable ?
Quels acteurs Membre devraient exister, et quel rôle fonctionnel, périmètre et relation hiérarchique chacun devrait-il utiliser ?

Si l'utilisateur a déjà un modèle, posez des questions de suivi jusqu'à ce que les propriétaires humains, les sous-agents IA, les rôles, les périmètres et les relations hiérarchiques soient clairs.

Si l'utilisateur n'a pas de modèle, demandez-lui s'il souhaite que vous proposiez un modèle de collaboration recommandé. Ne générez pas de modèle recommandé tant que l'utilisateur ne le demande pas.

Une fois le modèle d'équipe de collaboration compris ou proposé, générez une invite d'initialisation pour chaque Membre dans la conversation. Chaque invite doit dire à ce Membre de :

commencer explicitement avec $team-member-collaboration ;
lire AGENTS.md, COLLAB_LOG.md, éventuellement TEAM_TASKS.md et éventuellement MODULE_OWNERSHIP.md ;
comprendre le projet et le mécanisme de collaboration ;
préserver les exigences de langue de conversation et de document de l'utilisateur ;
confirmer ou créer leur identité d'acteur en utilisant le propriétaire humain, le rôle fonctionnel, l'instance et le périmètre convenus ;
vérifier les verrous de travail actifs avant de modifier ;
terminer l'initialisation du Membre et signaler l'ID d'acteur, le périmètre assigné et l'état de préparation.

Enregistrez le modèle convenu dans le registre des acteurs de AGENTS.md et, lorsque les modes de tâche ou de module sont activés, alignez TEAM_TASKS.md et MODULE_OWNERSHIP.md sur ce modèle.

Projet Vide

Traitez le dossier comme vide lorsqu'il n'y a pas de structure de projet évidente telle que README, source, documentation, application, configuration, package, tests ou scripts, ou lorsque l'utilisateur indique qu'il s'agit d'un nouveau projet.

Pour un projet vide, vous pouvez créer :

AGENTS.md
COLLAB_LOG.md

Vous pouvez suggérer une structure de dossiers légère, mais ne créez pas une architecture lourde sauf si l'utilisateur le demande.

Demandez ou déduisez :

Nom du projet.
Objectif du projet.
Pile technologique.
Si le mode d'attribution des tâches est souhaité.
Si le mode de propriété des modules est souhaité.
Si une disposition de répertoire de démarrage est souhaitée.

Projet Existant

Pour un projet existant, inspectez et préservez la structure actuelle. Vérifiez au moins :

README.md.
AGENTS.md existant, le cas échéant.
package.json, pyproject.toml, Cargo.toml, go.mod, ou fichiers de pile similaires.
Répertoires src, app, lib, docs, tests, frontend, backend, ou similaires.
Fichiers de règles de projet ou de contribution existants.
Statut Git.

Si AGENTS.md existe déjà, lisez-le et fusionnez-le avec soin. Ne l'écrasez pas.

Si un journal de collaboration similaire existe déjà, demandez s'il faut continuer à l'utiliser ou adopter COLLAB_LOG.md.

Si les règles de projet existantes sont en conflit avec les valeurs par défaut de Lite, arrêtez-vous et demandez :

Il y a un conflit entre les règles de projet existantes et le flux de travail de collaboration par défaut. Voulez-vous hiérarchiser les règles de projet existantes ou adopter les règles Lite recommandées ?

Recommandation par défaut : les règles de projet existantes l'emportent.

Question Obligatoire : Mode d'Attribution des Tâches

Demandez à l'utilisateur :

Voulez-vous activer le mode d'attribution des tâches ?

Expliquez brièvement :

Si activé, le Lead va :

Créer et maintenir TEAM_TASKS.md.
Diviser le travail en tâches.
Assigner les propriétaires des tâches.
Enregistrer le statut des tâches.
Définir le périmètre, les objectifs et les notes d'acceptation.
Examiner la production des membres lorsque nécessaire.
Mettre à jour le plan suivant.

Si non activé, utilisez le mode de coordination informelle :

Maintenez uniquement AGENTS.md et COLLAB_LOG.md.
Les membres travaillent à partir de l'instruction actuelle de l'utilisateur.
Tout le monde vérifie les verrous de travail actifs avant de modifier.
Tout le monde écrit une courte mise à jour une fois terminé.
Aucun tableau de tâches ni de flux de révision n'est requis.

Ne créez TEAM_TASKS.md qu'après que l'utilisateur a choisi le mode tâche.

Lorsque le mode d'attribution des tâches est activé, posez une question de suivi courte :

Qui peut marquer les tâches comme TERMINÉES ?

Politiques d'achèvement autorisées :

Révision par le Lead
Révision par l'utilisateur
Auto-achèvement par le Membre
Décision par tâche

Écrivez la politique d'achèvement sélectionnée dans AGENTS.md. Ne définissez pas par défaut chaque projet à la révision par le Lead, sauf si l'utilisateur le choisit.

Question Obligatoire : Mode de Propriété des Modules

Demandez à l'utilisateur :

Voulez-vous définir les limites et les propriétaires des modules maintenant ?

Si oui, créez ou mettez à jour MODULE_OWNERSHIP.md.

Si non, ne le créez pas. Les membres peuvent toujours se coordonner via AGENTS.md et COLLAB_LOG.md.

Règles de Verrouillage Doux

Les verrous doux sont des notes de collaboration, pas des verrous de sécurité.

COLLAB_LOG.md doit garder la section des verrous de travail actifs près du haut.

Les lectures rapides de AGENTS.md, COLLAB_LOG.md et des fichiers de tâches ne nécessitent pas de verrou. Les recherches ou analyses plus importantes peuvent utiliser un verrou reading.

Le mode Espace de Travail Partagé utilise la double vérification locale : lisez les verrous, écrivez votre verrou, puis revérifiez les verrous de travail actifs après avoir écrit votre propre verrou avant de modifier les fichiers métier.

Sémantique des conflits :

reading avec reading ne crée pas de conflit par défaut.
writing avec writing en chevauchement est un conflit.
reading avec writing en chevauchement nécessite un avertissement.
Si reading est uniquement une observation, il peut continuer.
Si reading est susceptible de devenir editing bientôt, demandez d'abord ou changez de périmètre.
paused réserve toujours le périmètre.
Seuil de péremption : 2 heures, sauf si AGENTS.md le remplace.
Ne retirez pas le verrou périmé d'un autre acteur sans confirmation de l'utilisateur ou du Lead.

Avant un travail de lecture/écriture plus important :

Lisez le dernier COLLAB_LOG.md.
Vérifiez les verrous en chevauchement.
S'il n'y a pas de chevauchement, ajoutez un verrou pour votre propre travail.
Revérifiez les verrous de travail actifs après avoir écrit votre propre verrou.
Si un autre acteur a créé un verrou en chevauchement en même temps, ne modifiez pas les fichiers métier. Expliquez le conflit et attendez une décision.

Traitez ceux-ci comme des chevauchements probables :

Même chemin de fichier.
Même dossier ou module.
Un verrou de module large qui contient le chemin de fichier demandé.
Une interface ou un contrat partagé que les deux tâches peuvent modifier.

Utilisez les chemins relatifs au dépôt pour le périmètre. Préférez les fichiers ou répertoires concrets. N'enregistrez pas de chemins absolus locaux.

Canonisation du Périmètre

Utilisez uniquement les chemins relatifs au dépôt.
Utilisez / comme séparateur.
Supprimez un ./ initial.
Réduisez les caractères / répétés.
Supprimez le / de fin sauf pour la racine du dépôt.
Séparez plusieurs chemins par ;.
Supprimez les espaces autour de chaque chemin.
Rejetez les chemins absolus.
Rejetez les segments de chemin ...
Les périmètres se chevauchent lorsque tout chemin canonisé est égal, parent/enfant ou partage une limite de module/interface déclarée.

Utilisez cette forme de verrou :

- ID d'acteur :
  Nom d'affichage :
  Rôle de collaboration : Lead | Membre
  Rôle fonctionnel :
  Statut : reading | writing | paused
  Périmètre :
  Tâche :
  Débuté :
  Dernière mise à jour :
  Fin prévue :
  Notes :

Lorsque le travail est terminé, supprimez votre verrou et ajoutez une courte entrée sous Dernières mises à jour.

Protocole de Verrouillage en Mode Git à Distance

Avant de modifier des fichiers métier en mode Git à Distance :

Récupérez le dernier état distant.
Relisez .collab/locks/*.md et .collab/tasks/*.md.
Vérifiez les verrous existants pour un chevauchement de périmètre.
Créez un enregistrement de verrou candidat dans .collab/locks/<actor-id>.md.
Validez uniquement le verrou candidat.
Poussez le verrou candidat vers la branche de collaboration.
Si le push signale non-fast-forward, récupérez, rebasez ou réappliquez le verrou candidat, relisez tous les verrous et réévaluez le chevauchement de périmètre.
Ne répétez pas le push à l'aveugle.
Ne forcez pas le push.
Modifiez uniquement les fichiers métier après que le verrou candidat est publié et revérifié sur le dernier état distant.

Si deux acteurs sont en compétition pour le même périmètre, un seul peut continuer. L'acteur perdant doit retirer le verrou candidat et s'arrêter avant les modifications métier.

Cycle de vie du verrou :

acquire : publiez un verrou candidat, revérifiez le dernier état distant, puis continuez.
refresh : mettez à jour Dernière mise à jour avant de continuer un travail long.
pause : conservez le périmètre réservé tout en étant temporairement arrêté.
resume : le même acteur revient et actualise le verrou avant de modifier.
release : supprimez ou marquez le verrou comme libéré, validez et poussez la modification.

Important : Ne validez jamais un verrou et des modifications métier dans le même commit. Gardez les verrous candidats comme des commits séparés pour permettre la détection de conflits.

Gestion des Transferts

En mode Git à Distance, utilisez l'un de ces deux schémas :

.collab/events/<timestamp>-<actor-id>.md : transfert direct de fichier unique (recommandé).
COLLAB_LOG.md : mise à jour de la section Transferts Ouverts.

En mode Espace de Travail Partagé, utilisez COLLAB_LOG.md : section Transferts Ouverts.

L'initiateur du transfert :

Décrit le travail à faire.
Énumère les fichiers et les chemins concernés.
Définit des critères d'acceptation si nécessaire.
Ajoute des notes sur l'état actuel, les connaissances contextuelles ou les décisions de conception.

Le récepteur du transfert :

Confirme la compréhension.
Décrit l'approche.
Signale la complexité estimée, les risques ou les questions.

Lorsque le travail est terminé, le récepteur du transfert met à jour ou ferme le transfert. Si le transfert utilisait .collab/events/, l'événement de fermeture peut être un nouvel événement ou une mise à jour du fichier d'événement d'origine.

Journalisation des Événements

En mode Git à Distance, un événement se produit lorsqu'un acteur :

met à jour sa propre identité ou la configuration du projet dans AGENTS.md.
acquiert, actualise, met en pause, reprend ou libère un verrou.
crée, met à jour ou résout une tâche.
initie, met à jour, commente ou résout un transfert.
change le statut de sa propre tâche, le périmètre ou le rôle fonctionnel.
termine ou annule une session.

Chaque événement est un fichier séparé dans .collab/events/ avec un horodatage et l'identité de l'acteur. Le contenu minimal de l'événement :

acteur :
type d'événement :
horodatage :
détails :

En mode Espace de Travail Partagé, un événement peut être un résumé ou une annonce directe dans COLLAB_LOG.md ou la conversation. Il n'y a pas de format obligatoire.

Journal d'Activité Interactif vs Concis

COLLAB_LOG.md peut être lu comme un journal interactif (détaillé) ou un journal concis (destiné à l'impression).
Utilisez le format concis lorsque les membres sont des agents avec des limites de jetons de contexte.
Utilisez le format interactif lorsque les membres sont humains, agents interactifs ou équipes mixtes.
Changez le format via une entrée de configuration dans AGENTS.md sous la section Paramètres du journal de collaboration.
Si le format n'est pas spécifié, supposez interactif.
Un journal concis peut inclure : l'instantané actuel, le nombre d'acteurs, les verrous actifs, les tâches ouvertes résumées et les transferts ouverts.

Garanties de Qualité

Ne présumez pas que l'utilisateur est un développeur senior. Expliquez les concepts si nécessaire.
Si l'utilisateur est confus, résumez les décisions et demandez une confirmation.
Si l'utilisateur donne une instruction incompatible avec le protocole de coordination, expliquez le conflit et proposez une alternative.
En cas d'ambiguïté, demandez.
Ne générez pas de charge de structure de projet sauf si cela est explicitement demandé.
Utilisez les fichiers de collaboration comme point de vérité, pas la conversation.
Ne présumez pas que l'autre participant exécute la même compétence. Utilisez un langage Markdown simple et des procédures de coordination de base.
Si un participant ne répond pas, attendez ou escaladez.
Ne retirez pas les verrous, tâches ou enregistrements d'un autre acteur sans confirmat.

Fin du Travail en Cours

Lorsqu'une phase ou une session est terminée, mettez à jour COLLAB_LOG.md :

Résumez ce qui a été accompli.
Mettez à jour les verrous actifs (libérez les vôtres).
Mettez à jour les tâches si le mode tâche est activé.
Mettez à jour les transferts ouverts.
Ajoutez des notes de décision ou des jalons.
Dans le journal concis, incluez une seule entrée récapitulative.

Si la session se termine de manière inattendue (panne du réseau, limite de jetons, erreur), ne marquez pas le travail comme terminé. Laissez les verrous en place ou marquez-les comme orphelins.

Résumé des Fichiers

Fichiers obligatoires :

AGENTS.md
COLLAB_LOG.md

Fichiers facultatifs :

TEAM_TASKS.md (activé par l'utilisateur)
MODULE_OWNERSHIP.md (activé par l'utilisateur)
.collab/locks/*.md (mode Git à Distance)
.collab/tasks/*.md (mode Git à Distance)
.collab/events/*.md (mode Git à Distance)
.collab/snapshots/COLLAB_LOG.md (mode Git à Distance, reconstruit par le Lead)

Gary06868/compétences-collaboration-agent-à-distance

Qu'est-ce que compétences-collaboration-agent-à-distance ?

Demander à votre IA préférée

Documentation