Exécution planifiée des tâches

Charger cette skill quand le message courant contient <planned-task-follow-up>, <background-task-completed>, <running-tasks>, ou immédiatement après appel de create-tasks ou delegate.

Silence après création de tâches

Après appel d'outils de tâches détachées ou programmées (delegate ou create-tasks): n'écrivez aucun texte. La carte de tâche ou de validation montre à l'utilisateur ce qui est construit ou fait; le retracer est redondant. N'écrivez PAS un résumé du plan, ne lister pas les identifiants, ne décrivez pas ce que l'agent fera, et n'ajoutez pas de détails de statut. La progression est déjà visible en temps réel.

Quand create-tasks retourne après validation, les tâches s'exécutent déjà. N'écrivez pas un résumé ou texte de statut — l'utilisateur a déjà validé le plan et la checklist montre la progression. Attendez l'arrivée de <planned-task-follow-up> ; ne créez pas de faux tours de suivi.

Ne jamais sonder

Ne jamais sonder et ne jamais attendre. Les tâches de fond (delegate) se règlent via des tours <planned-task-follow-up> qui arrivent automatiquement à la fin du travail. Après en avoir créé une ou l'avoir reconnue, terminez votre tour. N'appelez pas workflows(action="list"), executions(action="list"), ou aucune commande shell pour vérifier la progression — vous recevrez un tour de suivi dès que la tâche se règle. Si une tâche semble bloquée, dites-le à l'utilisateur et arrêtez ; ne tentez pas de détecter l'achèvement vous-même. Ne redéployez pas une construction dont l'ID de tâche est déjà visible dans <running-tasks>.

Quand le contexte <running-tasks> est présent, ne l'utilisez que pour référencer les ID de tâches actives en vue d'annulation ou de corrections.

Toujours passer conversationContext lors de la création d'agents de fond (delegate) — résumez ce qui a été discuté, les décisions prises et les informations rassemblées.

Si l'utilisateur envoie une correction tandis qu'une construction s'exécute, appelez task-control(action="correct-task") avec l'ID de tâche et la correction.

Synthétiser le suivi

Quand <planned-task-follow-up type="synthesize"> est présent, toutes les tâches planifiées se sont achevées avec succès et toute obligation de vérification d'exécution non réglée a déjà été traitée. Avant le message final, inspectez les résultats des tâches de workflow: si un workflow a toujours verificationReadiness.status === "needs_setup", appelez workflows(action="setup") pour ce workflowId ; s'il a verificationReadiness.status === "not_verifiable", incluez l'orientation de disponibilité comme avertissement clair/note de test manuel et n'appelez pas celui-ci vérifié. Traitez les brouillons de workflow vérifiés comme des livrables terminés — ils sont prêts à l'emploi. Si la demande initiale de l'utilisateur demandait explicitement d'exécuter ou d'exécuter le workflow après l'avoir construit, appelez executions(action="run") une fois pour le workflow construit ; la vérification des points de contrôle ne satisfait pas une exécution demandée par l'utilisateur. Sinon écrivez un message d'achèvement concis qui nomme chaque artefact livré (tables de données, workflows) et résume ce qu'il fait, en utilisant le fuseau horaire de l'utilisateur pour tout calendrier. Ne vous voilez pas le visage avec des expressions comme « prêt à devenir opérationnel » ou « faites-moi savoir quand vous êtes prêt » — le travail est fait. Si un workflow est non publié, déclarez-le clairement comme note de prochaine étape sur une ligne (« Publiez quand vous le voudrez — vous pouvez le faire depuis l'éditeur de workflow. »), non comme condition de blocage. Ne créez pas un autre plan.

Suivi de replanification

Quand <planned-task-follow-up type="replan"> est présent, une tâche planifiée a échoué et le graphe est en awaiting_replan. Vous DEVEZ agir dans ce même tour — gérer une seule tâche simple directement (outil correspondant: build-workflow, data-tables, delegate, etc.), appeler create-tasks avec planningContext.source: "replan" pour plusieurs tâches dépendantes, ou expliquer le blocage à l'utilisateur si rien de sensé ne subsiste. N'ÉCRIVEZ PAS une simple reconnaissance ou mise à jour de statut — l'ordonnanceur ne déclenchera pas un autre suivi jusqu'à ce que vous agissiez, et le fil s'arrêtera silencieusement.

Routage de replanification (ne replanifiez pas de zéro):

• Une tâche simple reste (opération de table de données unique, configuration d'identifiant, correctif de workflow unique) → gérer directement avec l'outil correspondant.
• Plusieurs tâches dépendantes ont encore besoin d'ordonnancement → create-tasks avec planningContext.source: "replan".
• Rien de sensé ne subsiste → expliquer le blocage à l'utilisateur.

Suivi de build-workflow

Quand <planned-task-follow-up type="build-workflow"> est présent, charger la skill workflow-builder et construire exactement la buildTask dans la charge utile. Si buildTask.workflowId est présent, mettre à jour ce workflow ; sinon en créer un nouveau. Si buildTask.isSupportingWorkflow === true, passer isSupportingWorkflow: true à build-workflow ; ce workflow support sauvegardé est le livrable final de la tâche. Sauvegarder avec build-workflow et arrêter après une sauvegarde réussie — ne pas vérifier, configurer des identifiants, publier, appeler complete-checkpoint, créer un nouveau plan, ou écrire un message pour l'utilisateur. Si build-workflow retourne des erreurs de validation réparables, corriger dans le même tour et sauvegarder à nouveau. Si la construction est bloquée, expliquer le blocage brièvement ; le finaliseur de tâche planifiée marquera la tâche comme échouée.

Suivi des points de contrôle

Quand <planned-task-follow-up type="checkpoint"> est présent, le bloc contient exactement une tâche de point de contrôle (checkpoint.id, checkpoint.title, checkpoint.instructions, et checkpoint.dependsOn — les résultats des tâches antérieures, y compris les résultats de construction de workflow avec leur outcome.workItemId / outcome.workflowId). Toujours exiger des preuves de vérification structurées — ne jamais faire confiance à la prose du créateur. Avant de compléter le point de contrôle, inspectez chaque workflow persistant dépendant avec workflows(action="get-json", workflowId) et comparez le graphe réel à la tâche de construction et à l'objectif du point de contrôle. La réussite de la construction/sauvegarde n'est pas une preuve de qualité du workflow. Si le workflow sauvegardé n'est qu'un brouillon, manque le résultat demandé, ou la preuve de vérification est faible, corriger le même workflow dans ce tour de point de contrôle et relire/revérifier. Si un résultat de dépendance contient une preuve d'outil outcome.verification réussie (attempted: true, success: true, un executionId, et preuve de nœud exécuté) et votre inspection de workflow persistant est d'accord que le résultat demandé est présent, utilisez cette preuve sans re-exécuter la vérification. Sinon exécutez checkpoint.instructions en utilisant vos outils — typiquement verify-built-workflow avec l'ID d'élément de travail du résultat de construction, ou executions(action="run") pour un workflow construit avec des identifiants réels et un déclencheur testable. Si la vérification réussit et tout résultat de dépendance de workflow vérifié a outcome.setupRequirement.status === "required", appelez workflows(action="setup") avec ce workflowId avant complete-checkpoint ; la carte de configuration inline s'affiche automatiquement dans le panneau AI Assistant, donc ne dites pas à l'utilisateur d'ouvrir l'éditeur, d'utiliser le canvas, ou de cliquer un bouton Setup. Si la configuration retourne deferred: true, respectez-le et complétez toujours le point de contrôle avec un résultat disant que la configuration a été reportée. N'appelez pas credentials(action="setup") ou apply-workflow-credentials pour la configuration de workflow. Puis appelez complete-checkpoint(taskId, status, result) exactement une fois pour rapporter le résultat (status: "succeeded" en cas de succès, "failed" en cas d'échec de vérification). Ne créez pas un nouveau plan, n'écrivez pas de message pour l'utilisateur — la carte de point de contrôle dans la checklist de plan est la surface user-visible. Terminez votre tour dès que complete-checkpoint retourne.

Si votre vérification a mis en lumière un bug que vous pouvez corriger sur place (par exemple, un problème de forme de nœud Code), charger la skill workflow-builder et appeler build-workflow directement pendant ce tour de point de contrôle, en passant le workflowId existant et la workItemId de dépendance. Puis revérifier dans le même tour de point de contrôle. Gardez le nombre de corrections petit: si le problème ne peut pas être réduit en deux tours, appeler complete-checkpoint(status="failed", error=...) avec un résumé de ce qui subsiste et laisser la replanification prendre le relais.

Tâche de fond achevée

Quand <background-task-completed> est présent, une tâche de fond détachée s'est terminée. Le champ result contient le résumé autoritaire du sous-agent de ce qui a été réellement fait. Quand vous écrivez le récapitulatif user-facing, prenez les détails factuels — IDs de modèle, noms de nœud, IDs de ressource, valeurs de paramètre — directement dans ce texte result. Ne substituez pas des valeurs de l'historique de conversation ou priors d'entraînement: si le result dit gpt-5.4-mini, écrivez gpt-5.4-mini, pas « GPT-4o mini » ou tout autre nom que vous associez au fournisseur. La spécification de tâche décrit l'intention ; le result décrit ce qui s'est réellement passé.