Workflows 2.0

NOUVEAU (Supercode 2.0.4+)

Workflows Maker Skill est maintenant disponible : générez des Supercode Workflows avec l'IA. Installez le skill depuis le menu Supercode → Tweaks.
Ensuite, demandez à l'agent IA de créer des workflows pour vous.

Important : Cursor prend en charge les Skills uniquement dans les versions nightly. Antigravity supporte Skills dans toutes les versions. Vous pouvez installer ce skill dans Claude Code.

Fin 2025, Skills et Workflows sont devenus les sujets les plus populaires en développement IA. Skills - un mécanisme simple mais extrêmement puissant qui est déjà pris en charge par la plupart des agents IA. Avec l'extension Supercode, vous pouvez maintenant créer et utiliser des Workflows de toute complexité et flexibilité dans Cursor.

Six mois après le lancement de Smart Actions, nous avons vu des centaines d'exemples de chaînes d'actions incroyablement longues et ramifiées créées par nos utilisateurs : des intégrations avec des trackers de tâches et des messageries à des cycles de développement entièrement automatisés avec refactorisation étape par étape, abstraction et extraction de modules, déduplication de code et couverture complète des tests.

Nous sommes fiers de ce résultat, et pendant ce temps nous avons reçu une énorme quantité de retours et de demandes d'améliorations. Aujourd'hui nous sommes heureux de présenter le mécanisme mis à jour : Workflows.

Cette mise à jour contient 3 fonctionnalités clés :

1. Workflows UI : maintenant toutes les étapes du Workflow sont créées dans une seule UI (ou fichier), en quelques clics, des dizaines de fois plus rapidement et facilement.
   
2. Workflow State : vous voyez le processus d'exécution et les informations pour chaque étape en temps réel
3. Smart Conditions : maintenant vous pouvez créer des conditions pour les étapes via JavaScript, des requêtes HTTP, des commandes shell, et même des requêtes IA, pour qu'il décide en fonction des données d'entrée si la vérification passe.
   

Pourquoi les Workflows ?

Pourquoi les Workflows sont-ils plus puissants que les Skills ? En quoi un workflow diffère-t-il de simplement fournir à l'agent une liste d'étapes ? Pourquoi les commandes shell dans les workflows sont-elles plus pratiques que les hooks ? Pourquoi avons-nous besoin d'étapes conditionnelles qui ne s'exécutent que dans certains cas ? Découvrons-le.

Les deux piliers principaux des workflows sont le déterminisme (exécution garantie) et l'encapsulation (isolation) des étapes futures. Derrière ces longs mots intimidants se cachent des idées simples : décomposons-les avec des exemples.

Exécution Garantie

Disons que nous envoyons le prompt suivant, modèle - Auto (c'est-à-dire Composer-1), à un projet frontend Next.js :

Naturellement, l'agent a immédiatement ajouté toutes les étapes à la liste des tâches et a commencé à travailler. Les première et deuxième étapes ont beaucoup chargé le contexte - lire ~30 fichiers a consommé presque 100k tokens. Disons qu'il y a eu des difficultés avec la troisième étape : l'agent a dû faire plusieurs itérations de corrections et vérifications via le navigateur intégré avant que le tableau ne fonctionne comme il le devrait. Dans le processus, il a créé des pages de test pour vérifier la fonctionnalité du tableau. À ce stade, le contexte est déjà rempli à 80%.

Quelle pensez-vous être la probabilité qu'après avoir terminé le travail sur le tableau, l'agent passe à créer la page /users ? Et à créer /products ?

Heureusement, nous n'avons pas à deviner : nous avons littéralement mené cette expérience avec un projet de test Next.js sur 7 modèles : Sonnet 4.5, Opus 4.5, Haiku 4.5, GPT-5.2, Composer-1, Gemini 3 Pro, Gemini 3 Flash, avec 5 exécutions pour chaque modèle. Le critère est simple - toutes les étapes ont-elles été terminées avec succès après une seule demande de l'utilisateur ?

Le résultat moyen pour Opus 4.5 et GPT-5.2 est 80% (8 tests réussis sur 10), Sonnet et Gemini 3 Pro - 60%, moyenne dans le groupe "Haiku, Composer-1 et Gemini 3 Flash" - 46% (7 sur 15).

C'est facile à remarquer - même les modèles phares, dans 1 cas sur 5, n'ont pas terminé la tâche depuis une seule demande. Le dernier groupe de modèles économiques populaires n'a pas terminé le travail dans la moitié des cas. En même temps, la tâche elle-même et le scénario de problème décrit sont assez typiques. Et si le workflow de l'utilisateur a 20 étapes, dont certaines ne devraient s'exécuter que sous certaines conditions ?

L'exécution garantie (déterminisme) est une propriété de base des Workflows : s'il y a une étape dans le workflow (envoi d'une tâche à l'agent, exécution d'un script, etc.), elle sera garantie de s'exécuter.

Isolation des Étapes Futures

Lorsque vous donnez au modèle un ensemble d'actions qu'il doit effectuer, il connaît toutes les actions à l'avance, et ne peut s'empêcher de prêter attention aux dernières pendant qu'il exécute les premières.

Ce concept est compréhensible pour les gens : si nous savons à l'avance quel résultat est attendu de nous, nous pouvons essayer d'adapter notre travail pour y arriver plus rapidement. Parfois c'est génial et peut gagner du temps. Mais il y a des processus où il est nécessaire de suivre méticuleusement les instructions ; sans eux, vous n'obtiendrez pas un bon résultat.

Pour faciliter, voici un exemple. Disons que nous donnons au modèle une tâche (application de bureau Electron ) :

Disons que ces fichiers ont deux types de fuites :

1. au lieu de supprimer le timer, il est désactivé : setInterval(() => { if (!active) return; ... })
2. nettoyage incorrect du cache global (niveau supérieur const map = new Map())

Et dans les 5 premiers fichiers dans src/watchers, seules des erreurs du premier type sont trouvées.

Souvent, un agent qui sait à l'avance qu'il est censé corriger des fuites essaiera de "prendre des raccourcis" : après avoir trouvé le même problème 5 fois de suite, il écrira "Vérifions immédiatement tous les fichiers avec une recherche regexp", cherchera setInterval, et seulement trouvera les fichiers qui avaient des problèmes du premier type, tout en manquant complètement le second type.

Le problème du "biais du résultat attendu" n'est pas résolu en augmentant l'intelligence ou le prix du modèle ; même les gens y sont sensibles. Dans les situations où la fourniture d'informations étape par étape améliore la qualité du résultat (analyse approfondie des fichiers avant refactorisation, examen complet de la documentation avant l'implémentation), les workflows garantissent que les informations sur les actions futures n'entrent pas dans le contexte de l'agent jusqu'au moment où elles doivent être exécutées.

Comparaison avec les Skills

Créer un Workflow

Les Workflows sont stockés dans des fichiers yml/json dans .supercode/workflows/ (local - à la racine du projet, global - dans le répertoire utilisateur).
Dans un fichier vous pouvez décrire un ou plusieurs workflows. Ils peuvent être stockés dans n'importe quel dossier imbriqué, par exemple, nous trouvons pratique de séparer les workflows dans un répertoire séparé et de stocker la description du workflow juste à côté des scripts utilisés (similaire aux Skills).

Paramètres Globaux

Un workflow a deux groupes de paramètres globaux - Déclencheurs et Configuration Avancée.

Dans le groupe de déclencheurs, vous pouvez configurer comment vous voulez lancer le workflow : en cliquant sur un bouton dans l'UI, et/ou en fonction d'une commande vocale. Note - même si vous n'avez sélectionné aucune des options, votre workflow est toujours disponible en cliquant depuis le menu Supercode > Workflows, et il peut toujours être lancé depuis un autre Workflow.

Dans le groupe Configuration Avancée, vous pouvez configurer le modèle par défaut et le mode agent qui seront sélectionnés lors du lancement du workflow. Note : si une étape du workflow remplace explicitement le modèle ou le mode - alors ce remplacement (pour cette étape spécifique) aura priorité sur les paramètres par défaut.

Étapes du Workflow

Un Workflow consiste en une séquence d'actions (étapes) qui seront exécutées dans l'ordre.

Une étape peut être une commande (prompt) pour l'agent IA dans votre IDE. Une étape peut être un appel de script. Ou elle peut former dynamiquement un nouveau prompt ou system prompt (en utilisant un script ou une requête IA). Elle peut remplacer le modèle actif actuel ou le mode agent. Une étape peut contenir une condition qui détermine si elle sera exécutée ou ignorée. Et elle peut également contenir un nombre illimité d'étapes imbriquées ou de références à d'autres Workflows. Examinons chacune de ces capacités en détail.

Trois Types d'Étapes

Dans chaque workflow, ainsi que dans toutes les actions imbriquées, vous pouvez créer trois types d'étapes :

1. Add Step : option standard, crée une étape régulière que vous pouvez configurer pour vos tâches.
2. Select Existing Action : crée une étape-lien vers un Workflow ou une Smart Action existante.
3. Add "Run Shell" action : crée une étape qui exécute une commande shell (par exemple, exécute un script Node.js ou Python).

Étape Standard

C'est le type principal d'étapes qui composent les Workflows. Chaque étape a :

• Nom
• Si cette étape doit lancer l'agent IA dans votre IDE (icône Run avec toggle)
• État actif (icône œil, avec lequel vous pouvez temporairement marquer les étapes inutilisées comme inactives)
• Ensemble de paramètres (prompt, system prompt, modèle, mode agent, commande IDE, condition d'exécution)
• Ensemble d'étapes imbriquées

Prompt et System Prompt

Il existe 5 façons de mettre à jour un prompt ou un system prompt :

1. Texte
2. Génération IA
3. Commande shell
4. Requête HTTP
5. Code JavaScript

Texte

C'est l'option la plus simple : vous pouvez simplement définir du texte statique pour le nouveau prompt, qui sera passé à l'agent IA. Ou vous pouvez utiliser des variables disponibles qui seront automatiquement remplacées par des valeurs du contexte actuel.

IA

C'est un mécanisme puissant qui vous permet de générer le texte d'un nouveau prompt en utilisant une requête à un modèle IA Supercode séparé. Vous pouvez également utiliser des variables disponibles (par exemple, le prompt actuel via $prompt), et demander à l'IA de retravailler la tâche : la décomposer en étapes, la traduire dans une autre langue, supprimer les parties inutiles, la structurer ou ajouter les détails manquants, considérer les nuances de sécurité , et bien plus encore. Imaginez que vous pouvez automatiquement améliorer votre prompt via ChatGPT avant de le passer à l'agent Cursor. C'est exactement ce que ce type de génération de prompt vous permet de faire.

Commande Shell

Ce type vous permet d'exécuter n'importe quelle commande shell (ou chaîne de commandes) et d'utiliser la sortie standard (stdout) de la commande comme nouveau prompt.
Y compris, les scripts peuvent être utilisés comme commandes : node ./my-script.js ou python ./get-data.py. En utilisant ce mécanisme, vous pouvez exporter du texte de tâches depuis des trackers de tâches , extraire les bugs actuels de Sentry, accéder aux APIs, bases de données, obtenir des informations des logs, et bien plus encore. Comme dans tous les autres cas - vous avez accès aux variables actuelles.

Requête URL

Ce type vous permet d'exécuter une requête POST vers n'importe quelle URL et d'utiliser la réponse (JSON) comme nouvelle valeur. Les variables actuelles sont envoyées dans le corps de la requête (application/json).

Code JavaScript

Ce type vous permet d'exécuter n'importe quel code JavaScript et d'utiliser son résultat comme nouvelle valeur. Les variables actuelles sont disponibles en tant que variables globales (pas besoin de préfixe de signe dollar pour y accéder, juste prompt, model, response, etc).

Variables Disponibles

Avec n'importe quel type de remplacement de prompt ou system prompt, vous pouvez utiliser des variables qui contiennent l'état du contexte actuel :

• $prompt - Texte du prompt actuel
• $systemPrompt - Texte du system prompt actuel
• $response - Dernière réponse de l'agent IA. Note : c'est littéralement le dernier message texte écrit par l'agent. Si l'agent a effectué plusieurs actions (édité des fichiers, réfléchi, exécuté des commandes dans le terminal, etc), alors cette variable contiendra exactement le tout dernier bloc de texte qui a été écrit par l'agent, pas tous ses messages texte depuis votre dernière demande. Cette variable est utile lorsque vous demandez à l'agent de terminer son travail avec une réponse texte : dans ce cas, cette réponse sera dans cette variable.
• $packedResponses - Tous les messages texte qui ont été envoyés par l'agent depuis votre dernière demande, empaquetés au format type XML (...<message from="ai-assistant">...</message>...). Cette variable est appropriée lorsque vous voulez analyser toutes les actions de l'agent depuis votre dernière demande.
• $model - Modèle actuellement sélectionné
• $mode - Mode agent actuel (agent/plan/debug/etc/ou nom du Mode Personnalisé)
• $initialPrompt - Le prompt qui était dans le champ de saisie lors du lancement du workflow.
• $initialModel - Le modèle qui était sélectionné lors du lancement du workflow.
• $initialMode - Le mode qui était sélectionné lors du lancement du workflow.

Mode et Modèle

Chaque étape du workflow peut changer le modèle actuel et le mode agent. Ce mécanisme vous permet d'adapter flexiblement le travail : utiliser des modèles plus intelligents pour planifier les changements, et moins chers pour éditer le code. Vous pouvez utiliser des modes analytiques pour explorer le code base et trouver des réponses à vos questions, puis activer automatiquement le mode Debug pour trouver et corriger les bugs.

Étapes Conditionnelles (Branchement)

Pour chaque étape, vous pouvez définir une condition qui sera vérifiée avant que l'étape ne commence à s'exécuter. Le mécanisme de condition est très similaire au mécanisme de mise à jour de prompt : vous avez également accès à toutes les variables, et presque toutes les options de lancement (sauf texte) : JavaScript, commande Shell, requête HTTP, et requête IA.

La différence clé réside dans quelle réponse est attendue de l'exécution de la condition :

• JavaScript : doit retourner une valeur booléenne (soit true/false explicite ou valeur truthy-falsy).
• Commande Shell : doit sortir avec le code 0 en cas de succès (l'étape s'exécutera), et une valeur non nulle en cas d'erreur (l'étape sera ignorée).
• Requête HTTP : doit retourner un statut 2xx en cas de succès (l'étape s'exécutera), et tout autre statut en cas d'erreur (l'étape sera ignorée).
• Requête IA : doit retourner le texte "true", "yes", ou "1", alors l'étape s'exécutera, sinon - sera ignorée.

La combinaison de conditions et d'étapes imbriquées vous permet de créer des branches et des boucles de toute complexité.

Commande IDE

Vous pouvez définir une commande IDE, qui sera exécutée au moment où cette étape s'exécute. Ce mécanisme vous permet de gérer l'environnement dans votre workflow : ouvrir un nouveau chat, réinitialisant ainsi le contexte, lancer la compilation du projet via des tâches npm, créer de nouveaux fichiers, et bien plus encore.

Étapes Imbriquées

Vous pouvez créer des étapes imbriquées qui seront exécutées à la fin de l'exécution de l'étape actuelle (après que ses actions principales pour écraser les prompts, lancer l'agent IA, etc. aient déjà été exécutées). Ce mécanisme fonctionne exactement de la même manière que les étapes principales dans un workflow : vous pouvez créer des actions supplémentaires , des références à d'autres workflows, exécuter des scripts, etc. Grâce à la capacité de créer autant d'étapes imbriquées que vous le souhaitez (et de les imbriquer les unes dans les autres), vous pouvez décrire n'importe quel scénario que vous imaginez en utilisant des workflows.