[{"data":1,"prerenderedAt":31},["ShallowReactive",2],{"doc:fr:workflows":3},{"title":4,"lede":5,"html":6,"headings":7},"Les workflows d’un projet","Un workflow est la suite d’étapes que tes agents suivent dans un projet (GSD, Superpowers, une boucle PROMPT.md…). Escouade le lit sur ta machine, sans rien dépenser, et dit où en est chaque agent. Cette page dit ce qu’elle suit de chaque harness et ce que le serveur MCP en donne.","\u003Cdiv class=\"callout note\">\u003Cp class=\"callout-title\">À noter\u003C\u002Fp>\u003Cp>Le mot est « workflow ». Une « boucle » reste le tour d’un ticket (« boucle 2\u002F5 »), et un retour en arrière dans un workflow s’appelle un retour.\u003C\u002Fp>\n\u003C\u002Fdiv>\n\u003Ch2 id=\"ce-qu-escouade-lit\">Ce qu’Escouade lit\u003C\u002Fh2>\n\u003Cp>Escouade ne demande rien à l’agent. Elle lit les commandes (\u003Ccode class=\"key\">.claude\u002Fcommands\u003C\u002Fcode>), les skills, les sous-agents et les prompts de chaque harness (\u003Ccode class=\"key\">.claude\u002F\u003C\u002Fcode>, \u003Ccode class=\"key\">.agents\u002F\u003C\u002Fcode> en entier, \u003Ccode class=\"key\">.github\u002F\u003C\u002Fcode>, \u003Ccode class=\"key\">.opencode\u002F\u003C\u002Fcode>, \u003Ccode class=\"key\">.cursor\u002F\u003C\u002Fcode>), sous le dossier du projet et dans les dossiers propres des harness, puis les fichiers d’état que les étapes écrivent (\u003Ccode class=\"key\">.planning\u002FSTATE.md\u003C\u002Fcode>, \u003Ccode class=\"key\">fix_plan.md\u003C\u002Fcode>…). Un workflow, ce sont au moins deux étapes reliées, ou un prompt rejoué ; une commande seule (\u003Ccode class=\"key\">\u002Fcommit\u003C\u002Fcode>) n’en est pas un.\u003C\u002Fp>\n\u003Cp>Pour chaque workflow, elle garde :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>ses \u003Cstrong>portes d’entrée\u003C\u002Fstrong> : les commandes ou skills par où l’on entre ;\u003C\u002Fli>\n\u003Cli>ses \u003Cstrong>étapes\u003C\u002Fstrong>, chacune avec sa commande, ses sous-agents et les fichiers qu’elle lit et écrit ;\u003C\u002Fli>\n\u003Cli>ses \u003Cstrong>retours\u003C\u002Fstrong> : un retour vers une étape déjà passée, avec la ligne qui dit quand et le nombre de fois au plus ;\u003C\u002Fli>\n\u003Cli>ses \u003Cstrong>fichiers d’état\u003C\u002Fstrong>, et ce qu’ils disent (« phase 3 sur 6 », « 12 cases cochées sur 20 ») ;\u003C\u002Fli>\n\u003Cli>sa \u003Cstrong>condition de sortie\u003C\u002Fstrong>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"ou-c-est-garde\">Où c’est gardé\u003C\u002Fh2>\n\u003Cp>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 \u003Ccode class=\"key\">.escouade\u002Fworkflows\u002F\u003C\u002Fcode>, à côté des \u003Ca href=\"\u002Fdocs\u002Fshared-board\u002F\">tickets partagés\u003C\u002Fa>. 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).\u003C\u002Fp>\n\u003Cul>\n\u003Cli>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.\u003C\u002Fli>\n\u003Cli>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 ».\u003C\u002Fli>\n\u003Cli>Les fichiers sont relus quand ils changent (un \u003Ccode>git pull\u003C\u002Fcode>, une autre branche) ; un fichier illisible est signalé avec son chemin et sa raison.\u003C\u002Fli>\n\u003Cli>Les workflows de tes propres dossiers (\u003Ccode class=\"key\">~\u002F.claude\u003C\u002Fcode>, \u003Ccode class=\"key\">~\u002F.codex\u003C\u002Fcode>, 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 \u003Ccode>~\u002F.escouade\u002Fprojects\u002F<id>\u002Fworkflows\u002F\u003C\u002Fcode>, jamais dans le dépôt. « Sur cette machine », dans Réglages › Projets › Workflow, y garde aussi ceux du dépôt.\u003C\u002Fli>\n\u003Cli>L’historique des agents dans les workflows reste sur ta machine, dans le dossier de données d’Escouade.\u003C\u002Fli>\n\u003Cli>Le format est décrit par un schéma JSON : \u003Ccode>https:\u002F\u002Fescouade.dev\u002Fschemas\u002Fescouade-workflow.schema.json\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"ou-en-est-chaque-agent\">Où en est chaque agent\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"ce-que-chaque-harness-permet-de-suivre\">Ce que chaque harness permet de suivre\u003C\u002Fh2>\n\u003Cdiv class=\"table\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Harness\u003C\u002Fth>\n\u003Cth>L’étape\u003C\u002Fth>\n\u003Cth>Le sous-agent en cours\u003C\u002Fth>\n\u003Cth>Le coût par étape\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Claude Code (conversation)\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Claude Code (vue Claude Code)\u003C\u002Ftd>\n\u003Ctd>oui, par ses hooks\u003C\u002Ftd>\n\u003Ctd>oui, par ses hooks\u003C\u002Ftd>\n\u003Ctd>à la fin du tour\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>OpenCode\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Copilot CLI\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003Ctd>oui\u003C\u002Ftd>\n\u003Ctd>le coût du tour, selon l’offre du compte\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Codex\u003C\u002Ftd>\n\u003Ctd>par ses prompts et les fichiers d’état\u003C\u002Ftd>\n\u003Ctd>non\u003C\u002Ftd>\n\u003Ctd>par tour\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Cursor CLI\u003C\u002Ftd>\n\u003Ctd>par ses commandes et les fichiers d’état\u003C\u002Ftd>\n\u003Ctd>oui, selon ACP\u003C\u002Ftd>\n\u003Ctd>non\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Cursor CLI (vue Cursor)\u003C\u002Ftd>\n\u003Ctd>par son transcript, à quelques secondes près\u003C\u002Ftd>\n\u003Ctd>non\u003C\u002Ftd>\n\u003Ctd>non\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>Trois précisions vues en vrai : une porte que l’agent lance seul (Claude Code appelle \u003Ccode class=\"key\">\u002Fecrire\u003C\u002Fcode> par son outil \u003Ccode class=\"key\">Skill\u003C\u002Fcode> dans le tour de \u003Ccode class=\"key\">\u002Fetude\u003C\u002Fcode>) 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.\u003C\u002Fp>\n\u003Ch2 id=\"par-le-serveur-mcp\">Par le serveur MCP\u003C\u002Fh2>\n\u003Cp>Trois outils, tous en lecture seule (voir \u003Ca href=\"\u002Fdocs\u002Fmcp\u002F\">le serveur MCP\u003C\u002Fa> pour les autres) :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>\u003Ccode class=\"key\">get_workflow\u003C\u002Fcode>\u003C\u002Fstrong> (\u003Ccode class=\"key\">project\u003C\u002Fcode>) : 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 (\u003Ccode class=\"key\">back\u003C\u002Fcode>, avec leur \u003Ccode class=\"key\">condition\u003C\u002Fcode> et leur \u003Ccode class=\"key\">max\u003C\u002Fcode>) et, sur chaque étape, les agents qui y sont maintenant (\u003Ccode class=\"key\">agentsHere\u003C\u002Fcode> : id, nom, depuis quand, Nᵉ passage). Les agents qui suivent un workflow sans être sur une étape sont à part (\u003Ccode class=\"key\">agentsElsewhere\u003C\u002Fcode>).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode class=\"key\">list_agents\u003C\u002Fcode>\u003C\u002Fstrong> : chaque agent gagne \u003Ccode class=\"key\">workflow\u003C\u002Fcode>, son nom, son étape, son tour (celui d’un prompt rejoué, ou la boucle de son ticket) et depuis quand ; \u003Ccode class=\"key\">null\u003C\u002Fcode> quand il n’en suit aucun.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode class=\"key\">get_agent_summary\u003C\u002Fcode>\u003C\u002Fstrong> : le même \u003Ccode class=\"key\">workflow\u003C\u002Fcode>, et l’historique des étapes (\u003Ccode class=\"key\">history\u003C\u002Fcode>, les 100 derniers passages, du plus ancien au plus récent).\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3 id=\"projets-prives\">Projets privés\u003C\u002Fh3>\n\u003Cp>Un \u003Ca href=\"\u002Fdocs\u002Fsettings-projects\u002F\">projet privé\u003C\u002Fa> ne dit rien de ses workflows aux agents des autres projets : \u003Ccode class=\"key\">get_workflow\u003C\u002Fcode> 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.\u003C\u002Fp>\n\u003Ch2 id=\"a-lire-aussi\">À lire aussi\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fmcp\u002F\">Le serveur MCP\u003C\u002Fa> : tous les outils, et ce qu’un agent d’Escouade voit.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fplan\u002F\">Le bandeau Plan\u003C\u002Fa> : la liste de tâches et les sous-agents d’un agent, qui complètent son étape.\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fdocs\u002Fharness\u002F\">Les harness\u003C\u002Fa> : ce que chacun sait faire.\u003C\u002Fli>\n\u003C\u002Ful>\n",[8,12,15,18,21,24,28],{"id":9,"text":10,"depth":11},"ce-qu-escouade-lit","Ce qu’Escouade lit",2,{"id":13,"text":14,"depth":11},"ou-c-est-garde","Où c’est gardé",{"id":16,"text":17,"depth":11},"ou-en-est-chaque-agent","Où en est chaque agent",{"id":19,"text":20,"depth":11},"ce-que-chaque-harness-permet-de-suivre","Ce que chaque harness permet de suivre",{"id":22,"text":23,"depth":11},"par-le-serveur-mcp","Par le serveur MCP",{"id":25,"text":26,"depth":27},"projets-prives","Projets privés",3,{"id":29,"text":30,"depth":11},"a-lire-aussi","À lire aussi",1793283948895]