Les workflows d’un projet

Ce qu’Escouade lit

Escouade ne demande rien à l’agent. Elle lit les commandes (.claude/commands), les skills, les sous-agents et les prompts de chaque harness (.claude/, .agents/ en entier, .github/, .opencode/, .cursor/), sous le dossier du projet et dans les dossiers propres des harness, puis les fichiers d’état que les étapes écrivent (.planning/STATE.md, fix_plan.md…). Un workflow, ce sont au moins deux étapes reliées, ou un prompt rejoué ; une commande seule (/commit) n’en est pas un.

Pour chaque workflow, elle garde :

• ses portes d’entrée : les commandes ou skills par où l’on entre ;
• ses étapes, chacune avec sa commande, ses sous-agents et les fichiers qu’elle lit et écrit ;
• ses retours : un retour vers une étape déjà passée, avec la ligne qui dit quand et le nombre de fois au plus ;
• ses fichiers d’état, et ce qu’ils disent (« phase 3 sur 6 », « 12 cases cochées sur 20 ») ;
• sa condition de sortie.

Un projet à plusieurs dépôts a le workflow de chaque dépôt. La lecture se refait quand un fichier lu change, et à la demande.

Où c’est gardé

Ce qu’Escouade comprend d’un workflow tiré de la config du dépôt (ses portes, ses étapes, leurs sous-agents, ses retours, ses fichiers d’état) et tes corrections sont gardés dans le dépôt, un fichier par workflow dans .escouade/workflows/, à côté des tickets partagés. Escouade écrit ces fichiers et les tient à jour, mais ne les commite jamais : commite-les avec ton travail, et toute l’équipe qui utilise Escouade voit les mêmes workflows et les mêmes corrections. Un workflow est du dépôt quand sa porte d’entrée l’est, même si une étape appelle une skill de tes propres dossiers (elle est nommée telle quelle).

• Les fichiers ne gardent rien d’une machine : ni date, ni chemin absolu, ni l’état du travail (« phase 3 sur 6 » est relu sur place). Une relecture sans changement ne les touche pas.
• Le dossier fait foi : un coéquipier dont la machine ne lit pas un workflow le voit et le suit quand même. Une relecture ajoute un workflow nouveau et met à jour celui qui a changé, sans jamais supprimer un fichier ; on écarte un workflow par « Ce n’est pas un workflow » (son fichier le garde marqué) ou on supprime son fichier par « Retirer du dépôt ».
• Les fichiers sont relus quand ils changent (un git pull, une autre branche) ; un fichier illisible est signalé avec son chemin et sa raison.
• Les workflows de tes propres dossiers (~/.claude, ~/.codex, GSD ou Superpowers installés là) sont lus, montrés et suivis de la même façon, mais leur fichier reste sur ta machine, dans ~/.escouade/projects/<id>/workflows/, jamais dans le dépôt. « Sur cette machine », dans Réglages › Projets › Workflow, y garde aussi ceux du dépôt.
• L’historique des agents dans les workflows reste sur ta machine, dans le dossier de données d’Escouade.
• Le format est décrit par un schéma JSON : https://escouade.dev/schemas/escouade-workflow.schema.json.

Où en est chaque agent

Chaque agent est placé d’après ce qu’il fait : la porte qu’il a tapée, les sous-agents qu’il lance, les skills qu’il appelle, les fichiers d’état qu’il écrit, la fin de ses tours. Une étape commence au premier fait qui la signale et finit au premier fait d’une autre ; sa durée et son coût sont ceux des tours entre les deux.

Chaque passage dans une étape reste dans l’historique de l’agent : l’heure, la durée, le coût, ce qui s’y est fait, l’issue, et pour un retour, la raison que l’étape donne. L’historique est gardé après un redémarrage, avec l’agent. Un agent qui fait autre chose (son message ne vient d’aucune porte et ses outils ne signalent aucune étape) est « hors du workflow » jusqu’à la porte suivante.

Ce que chaque harness permet de suivre

Un suivi partiel est dit comme tel dans la fenêtre (« Suivi partiel »), avec ce qui manque. Rien n’est inventé : ce qu’un harness ne montre pas n’est pas deviné.

Trois précisions vues en vrai : une porte que l’agent lance seul (Claude Code appelle /ecrire par son outil Skill dans le tour de /etude) compte comme une porte, l’étape suit donc sans que tu aies tapé la seconde ; le coût d’un modèle local (OpenCode sur Ollama) est de 0 $, ce qui n’est pas un trou du suivi ; et dans la vue Cursor, une commande tapée est reconnue même si l’interface la remplace par son fichier.

Par le serveur MCP

Trois outils, tous en lecture seule (voir le serveur MCP pour les autres) :

• get_workflow (project) : les workflows du projet, comme l’onglet Workflow les montre. Pour chacun, ses portes, ses étapes (commande, sous-agents, fichiers lus et écrits), ses retours (back, avec leur condition et leur max) et, sur chaque étape, les agents qui y sont maintenant (agentsHere : id, nom, depuis quand, Nᵉ passage). Les agents qui suivent un workflow sans être sur une étape sont à part (agentsElsewhere).
• list_agents : chaque agent gagne workflow, son nom, son étape, son tour (celui d’un prompt rejoué, ou la boucle de son ticket) et depuis quand ; null quand il n’en suit aucun.
• get_agent_summary : le même workflow, et l’historique des étapes (history, les 100 derniers passages, du plus ancien au plus récent).

Un agent ne se met pas dans une étape par un outil : il y entre en faisant le travail, et c’est ce que ces outils lisent. Rien d’autre n’est exposé que ce que montre l’onglet : jamais un fichier du projet, ni une conversation.

Projets privés

Un projet privé ne dit rien de ses workflows aux agents des autres projets : get_workflow ne le trouve pas (dans les mêmes mots qu’un projet qui n’existe pas), et ses agents, leur étape et leur historique n’apparaissent dans aucune liste des autres. Ses propres agents, eux, ne voient que lui.

À lire aussi

• Le serveur MCP : tous les outils, et ce qu’un agent d’Escouade voit.
• Le bandeau Plan : la liste de tâches et les sous-agents d’un agent, qui complètent son étape.
• Les harness : ce que chacun sait faire.