agent-team

Mécanisme de collaboration "multi-sessions = multi-départements", ancré dans le dossier du projet. Il ne s'agit pas de jeu de rôle, mais d'un système de postes : chaque session a des responsabilités fixes, des limites d'écriture, une boîte de réception, des passations de consignes et des portes de validation.

Les limites à respecter en premier

Commencez par établir une base de projet adaptée au contexte métier, puis construisez la couche de collaboration. Le répertoire cible par défaut = le répertoire de travail courant ; si docs/ manque ou si les fichiers d'objectifs / de progression / de passation ne sont pas clairs, déterminez d'abord le type de projet : pour les produits internet / Vibe Coding, privilégiez vibe-project-foundation ; pour les autres contextes métier, utilisez d'abord le Skill de base métier dédié existant ou la structure de fichiers actuelle. Si aucune base appropriée n'existe, demandez d'abord l'objectif métier, les livrables, les critères de validation, les ressources du processus, les risques / méthodes de relecture, puis aidez l'utilisateur à créer une base métier minimale, avant de construire la couche de collaboration.
Les trois niveaux doivent être complets : niveau gestion / exécution / validation. La configuration minimale est lead, do, review ; ne scindez pas artificiellement les départements pour avoir "plus d'agents".
Avant de créer docs/collaboration/, d'ajouter / supprimer / remplacer un département, de créer la première session d'un département, ou de changer le routage inter-sessions ou le mode de notification, l'utilisateur doit d'abord confirmer ; les réveils courts déjà enregistrés comme automatiques / manuels suivent le fichier_départements.md sans confirmation répétée.
N'écrivez pas directement de code métier ; ce Skill ne fait que diagnostiquer l'équipe, construire la couche de collaboration, enregistrer les sessions et maintenir les règles de collaboration.
Si docs/collaboration/ existe déjà, ne l'écrasez pas ; lisez d'abord l'état actuel, puis déterminez s'il faut ajouter un département, enregistrer une session, mettre à jour les règles ou reconstruire.
Porte de validation avant démarrage : ne partez pas du principe qu'un "Aide-moi à configurer une équipe / un département" correspond par défaut à un développement de produit internet. Confirmez d'abord le livrable final du projet et le mode de création des sessions, puis recommandez les départements.

Règles de fonctionnement impératives

Ces règles doivent être incluses dans les artefacts générés, et toutes les missions ultérieures doivent les respecter :

Porte des trois types de nœuds : chaque fonctionnalité / étape ne fait progresser qu'un seul nœud de validation. Une fois le nœud du département terminé, faites d'abord rapport au service de coordination ; le service de coordination juge selon trois types : les nœuds de perception produit / les nœuds de limite majeure doivent être confirmés par l'utilisateur, les nœuds procéduraux / techniques peuvent être avancés de manière autonome, les nœuds qui peuvent être avancés de manière autonome mais qui affectent la visibilité du projet doivent être rapportés avec une courte fiche de nœud.
La boîte de réception est la source de vérité : les détails des tâches et les rapports sont écrits dans la boîte_de_réception.md du département correspondant ; chaque session de département ne fait qu'une seule déclaration de capacité de notification lors de la prise de poste / de la réception de la consigne, puis suit le mode "automatique / manuel" enregistré. La notification n'exprime que trois types d'état : nouvelle tâche / tâche terminée / blocage rencontré.
Le rapport de fin comprend quatre éléments : chemin de production, résultat de la vérification (y compris les éléments non vérifiés), reçu du journal, auto-vérification des erreurs. Si un élément manque, le service de coordination ne peut pas considérer la boucle comme fermée.
Le service de coordination n'absorbe pas de longs contextes : le service de coordination lit d'abord sa propre boîte de réception, ne vérifie que l'existence des reçus de journaux ; ce n'est que lorsque les rapports sont insuffisants, les reçus erronés, les conclusions des départements contradictoires ou que l'utilisateur le demande, qu'il lit le corps de texte minimal nécessaire.
L'indépendance du niveau de validation ne garantit pas une validation aveugle suffisante : le service de validation vérifie par lui-même, n'hérite pas du long contexte du service d'exécution, ne se fie pas au récit "déjà validé" ; mais il ne doit pas non plus se contenter de réexécuter le chemin heureux du service d'exécution. Tout ce qui implique ce que l'utilisateur voit / les invites / les messages d'erreur / la progression / l'état / les fenêtres contextuelles / le résumé des résultats / le nom du fichier exporté / la fenêtre de l'état du package doit être testé jusqu'à la sortie finale du worker / de l'UI / de l'utilisateur ; tester uniquement la couche engine/API/helper ne compte pas comme une réussite. Pour chaque risque clé, concevez au moins une sonde inverse.
L'affectation des tâches doit préciser la sortie de validation et le chemin d'échec obligatoire : l'affectation du service de coordination doit préciser sortie de validation et chemin d'échec obligatoire. La sortie de validation indique où l'utilisateur voit finalement le résultat / l'invite / l'erreur / l'état / la fenêtre contextuelle / le résumé des résultats / le nom du fichier exporté / la fenêtre de l'état du package ; tout ce qui implique un contenu visible par l'utilisateur ne doit pas se limiter à la couche engine/API/helper. Le chemin d'échec obligatoire liste au moins 1 à 3 scénarios d'échec, d'exception ou de limite qui brisent le chemin heureux. S'il manque, le département destinataire retourne la demande au service de coordination pour la compléter, sans improviser.
L'expérience avant les tests : laissez d'abord l'utilisateur expérimenter les fonctionnalités exécutables ; lorsqu'on atteint un nœud "l'utilisateur doit expérimenter l'App", le service de coordination ouvre par défaut directement l'App pour l'utilisateur, sans demander d'abord "Voulez-vous l'ouvrir ?", puis fournit une courte fiche d'expérience. Ce n'est qu'après confirmation explicite de l'utilisateur ("Expérience OK / Peut passer aux tests") que le service de test effectue le contrôle qualité professionnel.
L'intention de conception doit être visualisée : pour tout nœud impliquant l'UI, l'interaction, la présentation visuelle, la mise en page, la maquette de conception, le parcours utilisateur, le service de conception ne peut pas se contenter de descriptions textuelles, de wireframes ASCII, de tableaux Markdown ou de conclusions abstraites ; il doit fournir un aperçu visuel de l'intention de conception que l'utilisateur peut juger directement. L'aperçu de conception ne doit pas prétendre être équivalent à l'UI réelle de l'App ; la validation de l'UI réelle se fait sur la base de l'App en cours d'exécution / du routage réel / de la capture d'écran de la construction ou du package.
La confirmation de conception est indépendante de la confirmation fonctionnelle : le fait que l'utilisateur confirme que la direction fonctionnelle est OK ne signifie pas que le visuel / l'interaction sont approuvés. Tant que l'utilisateur n'a pas confirmé la direction visuelle / interactive de la conception, le service de coordination ne peut pas assigner la réalisation formelle au service de développement ; tout au plus, il peut faire avancer la faisabilité fonctionnelle ou l'évaluation technique.
Validation aveugle / inspection par échantillonnage selon déclenchement : lorsqu'une même chaîne fonctionnelle passe plusieurs cycles consécutifs sans blocage (par défaut 3 cycles, ajustable avec explication), que la chaîne traverse engine → worker → UI → sortie utilisateur, qu'elle implique des messages d'erreur / état / publication / package / sécurité / coûts à haut risque, ou que l'utilisateur / la coordination estiment que les preuves sont insuffisantes, un sous-agent déclenche une validation aveugle / une inspection par échantillonnage. Le sous-agent ne fait que rapporter la conclusion de la validation aveugle / de l'inspection, sans modifier le code ni autoriser automatiquement.
Risque / coût selon déclenchement : le service de sécurité n'intervient que lors des grandes étapes, avant la mise en ligne / l'envoi externe ou en cas de risque de confidentialité, d'autorisations, de clés, d'autorisations, de plateformes tierces, de configuration de production, etc. ; le service financier n'intervient que lors des nœuds de coût, se contente d'alerter et de faire remonter, sans bloquer la publication.
La décision finale appartient à l'utilisateur : après le passage des trois portes de validation, le service de coordination ne donne qu'une recommandation de libération ; le marquage comme terminé, la publication externe, le paiement, etc., sont confirmés par l'utilisateur.
Règle de routage : les clarifications (ne modifient pas l'artefact, ne tranchent pas, ne font pas progresser l'état) vont directement à la boîte de réception de l'autre partie ; toute modification / décision / changement d'état / libération / ajout / suppression de département passe par le service de coordination.
Déviation en cas d'échec des tests : après que l'utilisateur a confirmé que l'expérience est OK et que les tests commencent, si le service de test trouve des problèmes de pur code / qualité / chemin d'exception, il le rapporte au service de coordination, qui synchronise d'abord l'utilisateur avec une fiche de nœud, puis peut affecter le développement pour reprise ; seule une implication sur les compromis d'expérience, les changements de périmètre, les coûts / sécurité / publication, les choix de solution ou les questions majeures nécessite de s'arrêter et d'attendre la confirmation de l'utilisateur.

Décisions des trois types de nœuds par le service de coordination

Principe de jugement du service de coordination :

L'utilisateur est responsable de l'expérience produit, des choix fonctionnels, des jugements de conception et des décisions majeures sur les risques ; le service de coordination est responsable des processus techniques, de l'ordonnancement des départements, du contrôle qualité de routine et de l'avancement sans controverse. L'avancement autonome doit être accompagné d'un rapport succinct ; en cas de perception produit ou de changement de limite majeur, il faut s'arrêter pour confirmer.

A. Doit être confirmé par l'utilisateur

Tout nœud qui affecte l'expérience produit, la perception utilisateur, les choix fonctionnels, la conception de l'interface, le flux d'interaction, la présentation visuelle, la limite du MVP, la feuille de route produit, la mise en ligne, la livraison externe, une augmentation significative des coûts, ou un risque de confidentialité / sécurité / cloud / clés / autorisations, le service de coordination doit s'arrêter et laisser l'utilisateur confirmer.

Cas typiques :

Une fois la fonctionnalité terminée, l'utilisateur doit l'expérimenter.
Une fois l'UI / l'interaction / la maquette de conception terminée, un aperçu visuel doit être présenté à l'utilisateur.
Lorsque la production du service de conception ne contient que des descriptions textuelles, des wireframes ASCII, des tableaux Markdown ou des conclusions abstraites, le nœud de conception n'est pas considéré comme terminé.
Tant que l'utilisateur n'a confirmé que la direction fonctionnelle est OK, mais pas la direction visuelle / interactive, la réalisation formelle du développement ne peut pas commencer.
Lorsqu'une fonctionnalité doit être ajoutée, supprimée, reportée ou que son périmètre change, l'utilisateur doit juger.
Lorsque les tests sont réussis, la décision de verrouillage officiel ou de passage à l'étape suivante nécessite la confirmation de l'utilisateur.
Lorsque cela implique le cloud, le téléchargement, une clé API, un téléchargement réseau, des frais, une modification significative de la taille du package, l'utilisateur doit confirmer.

B. Le service de coordination peut avancer de manière autonome

Pour tout nœud procédural / technique que l'utilisateur n'est pas en mesure de juger et qui ne modifie pas l'expérience produit ou les limites majeures, le service de coordination peut avancer selon son jugement professionnel, sans demander à plusieurs reprises.

Cas typiques :

Une fois les limites du produit confirmées, affecter le service de conception pour une première ébauche d'interaction minimale.
Une fois l'ébauche de conception terminée, affecter le service de développement pour une évaluation de la réalisation.
Lorsque le visuel / l'interaction de la conception ont été confirmés par l'utilisateur, que l'évaluation technique est claire et que les risques sont maîtrisables, affecter le service de développement pour une réalisation formelle ; avant la confirmation de l'UI, seule l'évaluation de la réalisation / la faisabilité technique peut être avancée.
Une fois que l'utilisateur a confirmé que l'expérience est OK, affecter le service de test pour le contrôle qualité.
Si le service de test trouve des problèmes de pur code / qualité / chemin d'exception après que l'utilisateur a confirmé que l'expérience est OK, le service de coordination synchronise avec une fiche de nœud puis affecte le développement pour reprise.
Lorsqu'il n'y a pas de blocage P0/P1/P2 dans les tests, le service de coordination peut recommander la réussite et passer à la confirmation de verrouillage.
Actions de routine telles que journaux, passations, partage de recueils d'erreurs, enregistrement de la progression, validation légère, archivage de commit après confirmation de verrouillage par l'utilisateur.

C. Peut avancer de manière autonome mais doit faire rapport

Ce type ne nécessite pas de décision de l'utilisateur, mais le service de coordination doit informer l'utilisateur avec une courte fiche de nœud "jusqu'où j'ai avancé".

Exemple de fiche de nœud :

"L'évaluation du développement est terminée, mais l'UI n'est pas confirmée ; je n'ai affecté que le développement pour une évaluation de faisabilité technique."
"Le visuel / l'interaction de la conception sont confirmés et l'évaluation des risques de développement est maîtrisable ; j'ai affecté le développement pour une réalisation formelle."
"Après que tu as confirmé que l'expérience est OK, j'ai affecté le service de test pour le contrôle qualité."
"Les tests ont révélé des problèmes au niveau du code, sans compromis sur le produit ; j'ai affecté le développement pour reprise."
"Aucun blocage dans les tests, je prépare le verrouillage et l'archivage."
"Sécurité / Finance n'ont pas été déclenchés à ce nœud, donc ils ne sont pas intervenus."

Sortie de validation, chemin d'échec et validation aveugle / inspection par échantillonnage

L'affectation du service de coordination doit préciser "où regarder pour la validation" et "comment briser le chemin heureux" dans la tâche, sans se limiter à un objectif de validation abstrait.

Champs obligatoires pour l'affectation :

sortie de validation : où l'utilisateur voit finalement le résultat / l'invite / l'erreur / l'état / la fenêtre contextuelle / le résumé des résultats / le nom du fichier exporté / la fenêtre de l'état du package. Tout ce qui implique un contenu visible par l'utilisateur ne doit pas se limiter à la couche engine / API / helper.
chemin d'échec obligatoire : au moins 1 à 3 scénarios d'échec, d'exception ou de limite pour briser le chemin heureux.

Si l'un ou l'autre manque, le département destinataire doit retourner la demande au service de coordination pour le compléter, sans improviser.

Champs obligatoires pour le rapport de validation / de test :

niveau de validation : engine / adapter-service / worker-tâche d'arrière-plan / UI-sortie visible par l'utilisateur / état du package / niveaux non couverts.
sortie visible par l'utilisateur : la sortie finale réellement testée.
sonde inverse auto-conçue : au moins une par risque clé, expliquant comment prouver qu'il ne s'agit pas d'une simple réexécution du chemin heureux.
niveaux non couverts : les niveaux non couverts doivent être explicitement mentionnés, sinon écrire "aucun".
déclenchement de validation aveugle / inspection par échantillonnage par sous-agent : écrire la conclusion et la justification.

L'indépendance du niveau de validation ne garantit pas une validation aveugle suffisante. Le service de validation ne doit pas se contenter de réexécuter le chemin heureux du service d'exécution ; tout ce qui implique ce que l'utilisateur voit / les invites / les messages d'erreur / la progression / l'état / les fenêtres contextuelles / le résumé des résultats / le nom du fichier exporté / la fenêtre de l'état du package doit être testé jusqu'à la sortie finale du worker / de l'UI / de l'utilisateur ; tester uniquement la couche inférieure ne compte pas comme une réussite.

Conditions de déclenchement de la validation aveugle / inspection par échantillonnage :

Même chaîne fonctionnelle passe plusieurs cycles consécutifs sans blocage, par défaut 3 cycles, ajustable selon la description du projet.
La chaîne traverse engine → worker → UI → sortie utilisateur.
Implique des messages d'erreur, un état, une publication / un package, une sécurité, des coûts, etc., à haut risque.
L'utilisateur ou la coordination estiment que les preuves sont insuffisantes.

Une fois déclenché, le sous-agent ne fait que rapporter la conclusion de la validation aveugle / de l'inspection, sans modifier le code ni autoriser automatiquement.

Déviation en cas d'échec des tests

Le passage de l'expérience utilisateur de l'App signifie seulement que le flux d'expérience, les attentes fonctionnelles et la perception utilisateur peuvent passer aux tests professionnels ; cela ne signifie pas que la qualité du code, les chemins d'exception, l'état du package, les journaux, les conditions limites ont été validés. Si le service de test trouve des problèmes P0/P1/P2 ou d'autres problèmes de qualité, il rédige d'abord un rapport de validation et un [rapport] dans la boîte de réception du service de coordination. Le service de coordination doit d'abord synchroniser la conclusion avec l'utilisateur via une fiche de nœud, puis dévier selon la nature du problème :

Peut affecter le développement pour reprise de manière autonome : bogues de code pur, chemins d'exception, messages d'erreur, journaux, état du package, incohérence de sortie worker/UI, lacunes de couverture de test, etc., problèmes de qualité professionnelle ; ces problèmes ne nécessitent pas que l'utilisateur fasse un jugement de code.
Doit s'arrêter et attendre la confirmation de l'utilisateur : nécessité de modifier l'expérience produit, le périmètre fonctionnel, le plan de conception, la limite du MVP, la stratégie de conservation des données, les coûts, la sécurité, la confidentialité, le mode de publication, ou existence de plusieurs solutions de correction qui sacrifieraient l'expérience / le périmètre / les coûts / la vitesse.

La fiche de nœud doit préciser : conclusion du test, impact, raison de la reprise, implication ou non d'un compromis utilisateur, jugement du service de coordination, prochaine étape. La reprise autonome signifie seulement l'entrée dans la boucle de correction, pas la libération finale ; après la correction, retour au nœud d'expérience utilisateur / de test.

Verrouillage et archivage du commit

La passation de consigne n'est pas égale à un commit git. Lorsqu'un département termine un nœud, il met d'abord à jour la passation, les journaux, le rapport de la boîte de réception et les livrables nécessaires ; le commit est une action d'archivage du dépôt après que l'utilisateur a confirmé le verrouillage officiel.

Lorsqu'il n'y a pas de blocage P0/P1/P2 dans les tests et pas de blocage au niveau des risques / coûts, le service de coordination peut émettre une recommandation de libération et demander à l'utilisateur de confirmer le verrouillage officiel. Après confirmation de l'utilisateur, le service de coordination doit exécuter :

Exécuter git status --short.
Si l'espace de travail ne contient que des modifications liées à ce nœud, exécuter un commit d'archivage.
S'il existe des modifications non liées, des modifications non confirmées par l'utilisateur ou impossibles à attribuer, expliquer d'abord à l'utilisateur, ne pas faire de commit mélangé.
Si le projet n'est pas un dépôt git, expliquer que le commit est impossible, se contenter de l'enregistrement de verrouillage de la couche de collaboration.

Le commit d'archivage ne représente pas une publication externe ; la publication, l'envoi externe, le paiement, la mise en ligne restent décidés par l'utilisateur.

Nœud d'expérience App

Lorsqu'on atteint un nœud "l'utilisateur doit expérimenter l'App", le service de coordination ouvre par défaut directement l'App pour l'utilisateur, sans demander d'abord "Voulez-vous l'ouvrir ?". Si l'environnement actuel peut démarrer / ouvrir l'App, il le fait directement ; si le démarrage échoue, il explique la raison de l'échec, les commandes essayées et l'entrée que l'utilisateur peut ouvrir manuellement.

Format standard de la fiche d'expérience :

Entrée:
Points clés:
Méthodes suggérées:
Critère de jugement:

Exigences de la fiche d'expérience :

Entrée : indiquer à l'utilisateur par où entrer, par exemple "Doublage / Clonage vocal → IndexTTS2 Doublage émotionnel → Intensité émotionnelle".
Points clés : dire à l'utilisateur sur quoi se concentrer cette fois, ne mettre que 1-2 points clés.
Méthodes suggérées : donner 2-4 actions spécifiques, pour que l'utilisateur n'ait pas à réfléchir à la façon de tester.
Critère de jugement : dire à l'utilisateur qu'il lui suffit de répondre "Expérience OK" ou d'indiquer ce qui ne va pas.

Exemple :

Entrée: Doublage / Clonage vocal → IndexTTS2 Doublage émotionnel → Intensité émotionnelle
Points clés: Écouter si les trois niveaux sont distincts et naturels.
Méthodes suggérées:
- Essayer Joie + Retenu / Standard / Prononcé.
- Essayer si le Style dynamique de présentation orale prend par défaut Joie + Prononcé.
- Passer à Naturel pour voir s'il fixe Standard et affiche un message.
Critère de jugement: Si tu trouves ça bien, dis "Expérience OK" ; si quelque chose cloche, dis-moi précisément.

Nœud de confirmation visuelle de la conception

Pour tout nœud impliquant l'UI, l'interaction, la présentation visuelle, la mise en page, la maquette de conception, le parcours utilisateur, le service de conception doit fournir un aperçu visuel de l'intention de conception que l'utilisateur peut juger directement, sans se contenter de descriptions textuelles, de wireframes ASCII, de tableaux Markdown ou de conclusions abstraites. L'aperçu de l'intention de conception sert à juger la direction, la mise en page, la hiérarchie de l'information et la sensation d'interaction, et ne doit pas prétendre être équivalent à l'UI réelle de l'App.

La validation de l'UI réelle doit provenir de l'App en cours d'exécution, du routage réel, de l'artefact de construction ou de la capture d'écran de l'état du package. L'OpenDesign / Figma / maquette HTML / PNG du service de conception ne sert que de base pour l'intention de conception ; après la réalisation par le service de développement, les écarts par rapport à l'intention de conception doivent être signalés, et le service de test vérifie si l'UI réelle de l'App s'en écarte.

Priorité de livraison du service de conception :

Utiliser en priorité des outils de conception dédiés comme OpenDesign pour générer des artefacts de conception modifiables ou des artifacts.
Si la session actuelle n'a pas chargé à chaud l'MCP OpenDesign, si OpenDesign n'a pas de projet actif, si les autorisations sont insuffisantes, si la connexion à l'outil a échoué, le service de conception doit clairement indiquer la raison de l'échec dans son rapport.
Lorsque l'outil n'est pas disponible, utiliser impérativement du HTML local + capture d'écran PNG, Figma, un aperçu d'image ouvrable, etc., comme solution de repli, pour garantir que l'utilisateur voit l'intention de conception, mais sans promettre qu'il s'agit de l'UI finale réelle.
Si l'utilisateur ne souhaite pas installer, démarrer, autoriser, enregistrer ou réparer OpenDesign, ou n'est pas disposé à recharger / ouvrir une nouvelle session pour la session en cours, le service de conception ne doit pas bloquer ; il doit choisir directement selon la préférence de l'utilisateur : HTML local + PNG, Figma ou aperçu d'image ouvrable.

Le "chemin de production" dans le rapport de fin du service de conception doit inclure simultanément :

Le chemin du document de spécification de conception.
Le chemin de l'aperçu de l'intention de conception, comme le lien de l'artefact OpenDesign / HTML local / capture d'écran PNG / lien Figma / image ouvrable.
En cas d'utilisation d'une solution de repli, l'état actuel d'OpenDesign et les conditions de rétablissement ultérieures doivent être clairement indiqués.

Règles d'intégration d'OpenDesign :

Vérifier d'abord si l'App OpenDesign locale est en cours d'exécution, puis vérifier l'état de santé du démon.
Ne pas supposer que le port par défaut est toujours 7456 ; confirmer l'URL réelle du démon à partir des journaux d'OpenDesign ou des ports d'écoute de la machine locale.
Après confirmation, enregistrer l'MCP open-design dans Codex ; la session actuelle peut ne pas être en mesure de charger à chaud un nouvel MCP, et si nécessaire, inviter l'utilisateur à recharger / ouvrir une nouvelle session.
Si l'écriture de l'artefact OpenDesign indique qu'il n'y a pas de projet actif, demander à l'utilisateur de créer un projet dans OpenDesign ou de cliquer dans un projet, ou livrer directement avec du HTML local / PNG comme solution de repli, sans bloquer le nœud.
Si OpenDesign n'est pas installé / pas en cours d'exécution, si les autorisations sont insuffisantes, si la connexion a échoué ou si l'MCP n'est pas chargé à chaud, le service de conception doit demander activement à l'utilisateur s'il a besoin d'aide pour l'installation / le démarrage / l'autorisation / l'enregistrement de l'MCP / le rechargement ou l'ouverture d'une nouvelle session ; si l'utilisateur ne traite pas, passer immédiatement à une solution de visualisation de repli.
Ordre de dépannage minimal : vérifier si l'App est en cours d'exécution → vérifier le port d'écoute ou l'URL du démon dans les journaux → vérifier si l'MCP est enregistré / si la session actuelle est chargée à chaud → vérifier le projet actif → vérifier les autorisations / les erreurs de connexion ; en cas d'échec à une étape, fournir simultanément une solution d'aperçu de repli.
OpenDesign n'est qu'un outil pour améliorer l'expression de la conception et la capacité de confirmation visuelle, et ne signifie pas une extension automatique à une refonte complète de l'UI, une mise à niveau de la marque ou une réalisation de développement.

Après réception du rapport de conception, le service de coordination :

Afficher d'abord l'aperçu de l'intention de conception, puis donner à l'utilisateur une courte fiche de nœud.
Structure suggérée pour la fiche de nœud : résultat / point de jugement / suggestion / risque / prochaine étape.
Ne pas jeter de longues explications techniques ou le corps du texte de conception directement à l'utilisateur pour qu'il juge.
Avant que l'utilisateur n'ait confirmé la direction visuelle / interactive de la conception, le service de développement ne peut pas être affecté à une réalisation formelle ; si l'utilisateur ne fait que confirmer que la direction fonctionnelle est OK mais que l'UI n'est pas confirmée, seule la faisabilité fonctionnelle ou l'évaluation technique peut être avancée.
Le jugement de l'UI après la réalisation du développement ne doit pas continuer à se référer à l'aperçu de l'intention de conception pour remplacer l'interface réelle ; il doit revenir à l'App réelle / au routage réel / à la capture d'écran de la construction ou de l'état du package.

Conditions d'arrêt de l'avancement autonome

L'avancement autonome du service de coordination ne signifie pas un avancement continu illimité. Les nœuds procéduraux peuvent être avancés de manière continue, mais dans les cas suivants, il faut s'arrêter et demander à l'utilisateur :

La conclusion est clairement incertaine.
Conflits de jugement entre départements.
Nécessité de sacrifier l'un des éléments suivants : expérience, périmètre, coûts, vitesse.
Nécessité d'ajouter une dépendance, un cloud, une connexion réseau, un modèle, un coût.
Nécessité de modifier la direction produit précédemment confirmée par l'utilisateur.
Entrée dans une fonctionnalité exécutable à expérimenter, une confirmation visuelle de l'UI, une publication / un package / un envoi externe, un verrouillage de grande étape.

Processus de diagnostic

Si l'utilisateur a déjà clairement indiqué le type de projet, le livrable et le mode de création des sessions, diagnostiquer directement ; ne pas répéter la question. Si les informations sont insuffisantes, ne poser qu'une question clé à la fois.

Première question :

Quel est le livrable final de ce projet : un logiciel exécutable, du contenu / un cours, un résultat opérationnel, un plan d'étude, un flux automatisé, une livraison hors ligne, ou autre chose ?

Deuxième question :

Comment les sessions de département seront-elles créées cette fois : par un Agent disposant d'un outil de gestion de sessions comme Codex, ou allez-vous d'abord créer manuellement les fenêtres de session de chaque département, et je ne fais que générer les fichiers du département et le guide d'intégration ?

Tant que la première question n'est pas clarifiée, ne recommandez pas la configuration courante product/design/dev/test pour un logiciel. Tant que la deuxième question n'est pas clarifiée, ne prétendez pas avoir créé les sessions de département. Si le projet manque de fichiers de base, déterminez d'abord s'il existe un Skill de base de scénario applicable ; sinon, créez une base métier minimale générique, sans orienter tous les projets vers vibe-project-foundation.

Lors du diagnostic, fixez les trois niveaux, ne jugez que le nombre de départements d'exécution et le nombre de portes de validation :

Dimension de déclenchement	Impact si atteint	Département
Logiciel / Produit internet / Vibe Coding / Artefact exécutable	Activer la configuration logicielle	`product/design/dev/test`
Lourd en UI / Interaction / Visuel	Renforcer la conception	`design`
Lourd en collecte d'informations, enquêtes utilisateur/marché/concurrence/vérification des faits	Ajouter la recherche	`research`
Lourd en planification, processus, calendrier, allocation des ressources	Ajouter la planification	`planning`
Lourd en collecte/nettoyage/importation/exportation/ exactitude des données	Ajouter les données	`data`
Exécution automatique par lots, programmée, multiplateforme	Ajouter l'automatisation	`auto`
Production continue de textes/images/vidéos/rapports	Ajouter le contenu	`content`
Croissance, conversion, rétention, monétisation	Ajouter la croissance et l'opérationnel	`growth`
Comptes, connexion, confidentialité, conformité, plateformes tierces, clés, configuration de production	Ouvrir la porte des risques	`security`
Budget, sensibilité aux coûts, éléments payants	Ouvrir la porte des coûts	`finance`
Fonctionnalités complexes, nécessitant une couverture de bogues/exceptions	Porte qualité indépendante	`test` ou `review`
Aucune dimension forte	Configuration minimale générique	`lead, do, review`

Pour les projets non logiciels, ne forcez pas l'application de produit/conception/développement/test ; jugez d'abord en fonction du livrable, des critères de validation, des ressources du processus, des risques et de la méthode de relecture. Si aucune catégorie ne correspond, utilisez lead, do, review, puis ajoutez research/planning/content/data/auto/security/finance en fonction des risques.

Choix de la base

La couche de collaboration dépend d'une base de projet qui permet aux départements de comprendre les objectifs et les limites, mais la base n'est pas nécessairement une structure de répertoire fixe pour un logiciel.

Ordre de traitement :

Vérifier d'abord si le projet dispose déjà d'une base utilisable : comme docs/, plan d'affaires, description de projet, liste de livrables, fichiers de progression / passation, répertoires spécifiques au secteur. Si c'est le cas, planifier les responsabilités des départements et les limites d'écriture en fonction de la base existante, sans forcer le changement en une structure logicielle.
S'il s'agit d'un produit internet, d'un logiciel, de Vibe Coding ou si des artefacts comme app/ design/ docs/spec.md sont clairement présents, alors seulement recommander ou utiliser vibe-project-foundation.
S'il s'agit d'un projet non logiciel (cours, contenu, opérations, conseil, livraison hors ligne, étude, processus interne, etc.), vérifier d'abord s'il existe un Skill de base métier dédié correspondant ou un modèle existant ; si oui, l'utiliser.
S'il n'existe pas de base dédiée, ne pas s'arrêter sur "Veuillez d'abord installer une base logicielle". Demander d'abord l'objectif métier, le livrable final, les critères de validation, les ressources du processus, les risques / la méthode de relecture, puis créer une base métier minimale.

La base métier minimale ne contient que les fichiers génériques nécessaires à la collaboration :

docs/overview.md : objectif du projet, livrable, public cible / utilisateur cible, limites.
docs/progress.md : phase actuelle, terminé, en cours, prochaine étape.
docs/agent-guide.md : règles de collaboration du projet, répartition des fichiers, points d'attention.
Si nécessaire, créer des répertoires comme deliverables/, materials/, research/, operations/, scratch/ en fonction du métier ; ne pas créer de répertoires logiciels non pertinents.

Lors de la recommandation d'équipe, fournir :

Quels départements pour chaque niveau, et la justification de la sélection.
Responsabilités, interdictions, entrées, sorties, périmètre d'écriture, périmètre d'écriture interdit pour chaque département.
Routage inter-départements : clarification directe ou via le service de coordination.
Quels nœuds doivent être confirmés par l'utilisateur.
Mode de création des sessions : Création automatique de sessions ou Création manuelle de fenêtres de session, et les étapes d'exécution correspondantes.

Avant de créer, s'arrêter pour confirmer :

Je suggère de créer docs/collaboration/ selon la configuration d'équipe ci-dessus, avec un mode de session [Création automatique / Création manuelle]. Confirmez-vous ?

Création de la couche de collaboration

Après confirmation, exécuter le script. S'il n'y a pas de base dédiée et que l'utilisateur confirme que ce Skill doit compléter la base métier minimale, ajouter --create-minimal-foundation --allow-without-foundation. Configuration minimale générique par défaut :

python3 <chemin_du_skill>/scripts/scaffold_team.py "<répertoire_du_projet_cible>" \
  --profile "<résumé_du_diagnostic_d'équipe>" \
  --session-mode "manual"

Pour un déploiement basé sur le diagnostic, transmettre explicitement les rôles :

python3 <chemin_du_skill>/scripts/scaffold_team.py "<répertoire_du_projet_cible>" \
  --profile "Logiciel + Données fortes + Implique confidentialité/plateforme + Budget" \
  --roles "lead,product,design,dev,data,test,security,finance" \
  --session-mode "auto"

Rôles optionnels :

Niveau gestion : lead
Niveau exécution : do/research/planning/product/design/dev/data/auto/content/growth
Niveau validation : review/test/security/finance

Le script crée docs/collaboration/README.md, fichier_départements.md, liste_démarrage_session.md, règles_routage_lecture.md, recueil_erreurs.md, modèle_passation_tâche.md, conclusions_spéciales/, scripts/agent_team_read.py et, dans départements/<nom_département>/, description_poste.md, guide_intégration.md, document_passation.md, boîte_de_réception.md, rapports/, journaux/<ISO_semaine>.md ; le niveau de validation dispose en outre de rapports_de_validation/ (sémantique de rapport de validation) compatible avec l'ancien nom. Le script refuse d'écraser une couche de collaboration existante, refuse les rôles en double, refuse une nouvelle équipe sans niveau gestion / exécution / validation ; il s'arrête si --session-mode auto/manual n'est pas transmis, afin d'éviter de contourner la confirmation du mode de session.

Mode de création des sessions

Création automatique de sessions (Codex / avec outil de gestion de sessions)

Après confirmation par l'utilisateur du mode automatique :

Exécuter d'abord le script pour créer docs/collaboration/.
Utiliser tool_search pour rechercher les outils de session create_thread, send_message_to_thread, set_thread_title ; l'épinglage, le tri ne sont pas des capacités nécessaires.
Lorsque l'outil est disponible, créer une session pour chaque département ; utiliser de préférence un préfixe numérique pour l'ordre, par exemple 01 Service de coordination, 02 Service produit, 03 Service développement.
Envoyer le guide_intégration.md de chaque département comme message d'initialisation à la session correspondante, en demandant à cette session de prendre d'abord le poste, de ne rapporter que les responsabilités / la phase / les tâches en cours / la boîte de réception / les questions en attente, sans effectuer immédiatement de tâche métier.
Écrire l'ID de session retourné dans docs/collaboration/fichier_départements.md, et enregistrer le mode de notification comme automatique. Si l'outil d'envoi échoue, passer le mode de notification de ce département à manuel et expliquer à l'utilisateur que la création automatique de session n'a pas abouti.
Enfin, rapporter à l'utilisateur : quelles sessions ont été créées, quels ID de session ont été enregistrés, lesquelles nécessitent un traitement manuel.

Si l'outil n'est pas disponible ou si l'appel échoue, ne pas dire "les sessions ont été créées" ; terminer en mode manuel.

Création manuelle de fenêtres de session (autres Agents / sans outil de gestion de sessions)

Après confirmation par l'utilisateur du mode manuel :

Exécuter uniquement le script pour créer docs/collaboration/ et les fichiers de chaque département.
Ne pas appeler d'outil de session, ne pas prétendre avoir créé des sessions.
Produire une liste de démarrage manuel : le chemin du guide_intégration.md pour chaque département, le nom de fenêtre suggéré, la première phrase que l'utilisateur doit coller à cette session.
L'ID de session dans docs/collaboration/fichier_départements.md reste à enregistrer, le mode de notification reste à enregistrer ou passe à manuel selon les instructions de l'utilisateur.
Une fois que l'utilisateur a créé manuellement les fenêtres, envoyer le guide_intégration.md de chaque département à la session correspondante ; la session de département exécute d'abord docs/collaboration/scripts/agent_team_read.py onboard --dept [nom_département], puis lit la description de poste, la passation, le recueil d'erreurs, la boîte de réception selon les fichiers obligatoires retournés par le script ; toutes les passations ultérieures sont écrites dans le boîte_de_réception.md du dossier du département correspondant.

Vérification après création :

La structure docs/collaboration/ est complète, les trois niveaux ont au moins un département chacun.
docs/agent-guide.md a été complété avec les instructions de collaboration multi-sessions.
docs/collaboration/liste_démarrage_session.md précise le mode automatique/manuel et le point d'entrée pour chaque département.
En mode automatique, fichier_départements.md a enregistré l'ID de session réel et le mode de notification ; en mode manuel, il est clairement indiqué que les sessions n'ont pas encore été créées.
docs/progress.md enregistre la création de la couche de collaboration, le résumé de la configuration de l'équipe, la prochaine étape.
git status --short ; si seules les modifications liées à cette couche de collaboration sont présentes, un commit séparé peut être effectué :

git add docs/agent-guide.md docs/progress.md docs/collaboration
git commit -m "chore: mise en place de la couche de collaboration multi-sessions"

Si le dépôt contient déjà d'autres modifications non engagées, ne pas faire de commit mélangé, expliquer à l'utilisateur.

Mode maintenance

Il peut être nécessaire d'ajouter / fusionner / supprimer des départements, de remplacer des sessions, d'enregistrer des ID de session, d'ajuster les limites, d'affecter des tâches ou d'effectuer une validation indépendante. Principes de traitement :

Lire d'abord docs/collaboration/fichier_départements.md pour confirmer les trois niveaux et départements existants.
Déterminer si cela brise la règle "au moins un pour chaque niveau" ou les limites de responsabilité.
Toute action impliquant l'ajout / la suppression / le remplacement d'un département, un message inter-session, une libération, une reprise, une mise à niveau d'état, doit d'abord être confirmée par l'utilisateur.
Pour ajouter un département, utiliser scaffold_team.py <projet> --add-roles "<ids>" ; le script ne fait que créer les départements manquants et les ajouter au fichier des départements, nécessite toujours une synchronisation manuelle des règles de routage affectées.
Pour supprimer / fusionner un département, d'abord consigner les affaires en cours et l'historique dans les journaux, puis mettre à jour le fichier des départements et les descriptions de poste associées ; ne pas supprimer directement l'historique.
L'enregistrement de la capacité de notification ne se fait qu'une seule fois lors de la prise de poste / de la réception de la consigne :
- Lire le "mode de notification" de ce département dans fichier_départements.md. S'il est enregistré comme automatique ou manuel, cette session suit ce mode pour toutes les notifications ultérieures, sans redétecter l'outil à chaque tâche terminée.
- Si le mode de notification est à enregistrer, et qu'il existe tool_search, rechercher des outils d'envoi comme send_message_to_thread ; s'il n'y a pas de tool_search ou si aucun outil d'envoi n'est trouvé, enregistrer comme manuel.
- automatique : pour les notifications ultérieures, appeler par défaut directement l'outil d'envoi de session pour un court réveil, sans vérifier au préalable la capacité.
- manuel : pour les notifications ultérieures, donner par défaut directement à l'utilisateur un court réveil copiable, en lui demandant de rappeler manuellement le département cible.
- Si l'appel en mode automatique échoue en pratique, revenir à un rappel manuel pour cette fois et demander à l'utilisateur d'informer le service de coordination pour mettre à jour fichier_départements.md.
- Si l'utilisateur constate un changement dans la capacité des outils de l'Agent, demander à l'utilisateur d'en informer la session du service de coordination, qui mettra à jour le mode de notification dans fichier_départements.md.
Priorité de routage par la lecture :
- Une nouvelle session de département ou une session de réception de consigne exécute d'abord en priorité python3 docs/collaboration/scripts/agent_team_read.py onboard --dept [nom_département], afin que le script retourne l'identité de ce département, le mode de notification, les fichiers obligatoires et les limites de lecture par défaut.
- Les rapports, rapports de validation, conclusions spéciales, décisions clés utilisent un frontmatter YAML avec les champs type / department / target / status / date / related_task / decision / tags / summary ; le script ne retourne que ces champs pré-écrits manuellement, sans faire de résumé créatif.
- Avant de rechercher des preuves, exécuter d'abord en priorité agent_team_read.py find --type audit_report --status blocked, agent_team_read.py find --type special_conclusion --tag sortie_visible_utilisateur ou agent_team_read.py meta <path> ; ce n'est que lorsque le résumé est insuffisant, le chemin anormal, les conclusions contradictoires, qu'il implique une libération / une reprise / la sécurité / des coûts / une publication / une qualité visible par l'utilisateur, que l'utilisateur demande des preuves, ou que la tâche en cours dépend clairement du corps du texte, qu'il faut lire le corps du texte minimal nécessaire.

AidenXu-1/agent-team-skill

Qu'est-ce que agent-team-skill ?

Demander à votre IA préférée

Documentation