Planification

Utilisez cette compétence pour concevoir un graphe de tâches conscient des dépendances dans l'orchestrateur et le soumettre avec create-tasks. Ne lancez pas un autre agent, ne déléguez pas l'étape de planification, et n'utilisez pas d'outils de planification par étapes.

La planification est destinée aux travaux nécessitant une coordination : workflows multiples, dépendances entre workflows, schéma de table de données partagé ou travail de migration, artefacts durables multiples, recherche de meilleures pratiques étendue, architecture de processus métier ambiguë, ou demande explicite de l'utilisateur de d'abord examiner un plan.

Les builds de workflow unique clairs et les modifications de workflow existant utilisent la compétence workflow-builder avec build-workflow directement. Le travail de table de données autonome utilise la compétence data-table-manager avec les appels directs data-tables et parse-file.

Méthode

Décidez si la demande justifie une planification selon le besoin de coordination, non selon qu'un workflow est nouveau.
Découvrez ce qui affecte matériellement le plan avec les outils normaux : nodes(action="suggested"), credentials(action="list"), data-tables(action="list"), parse-file, workflows, et research si pertinent.
Préférez les hypothèses raisonnables aux questions. Posez des questions à l'utilisateur seulement si la réponse changerait matériellement le plan et ne peut pas être découverte.
Construisez un graphe conscient des dépendances. Les producteurs doivent venir avant les consommateurs. Les tâches indépendantes ne doivent pas dépendre les unes des autres.
Placez les exigences de table locales à un seul workflow dans la spécification de tâche de ce workflow. Ne créez pas de tâches de table de données séparées sauf si le travail de table est un artefact durable partagé entre les tâches.
Ajoutez des tâches de point de contrôle uniquement pour les vérifications sémantiques exceptionnelles que la vérification normale du workflow ne peut pas couvrir.
Appelez create-tasks avec planningContext.source: "planning-skill", un summary concis, des assumptions optionnels, postBuildRunRequested: true uniquement si l'utilisateur a explicitement demandé d'exécuter, lancer ou tester un workflow après sa construction, et le graphe de tâche final.
Après l'appel de create-tasks, n'écrivez pas de texte visible. La carte d'approbation est la surface visible pour l'utilisateur.

Règles du graphe de tâches

Utilisez les types de tâche exactement comme supportés : build-workflow, delegate, et checkpoint.
Chaque id de tâche doit être stable et référencé par les arêtes de dépendance.
Chaque title doit être court et orienté utilisateur.
Chaque spec doit être le briefing complet pour l'exécuteur de cette tâche. L'exécuteur de tâche peut ne pas voir vos notes de planification plus larges.
Pour les tâches build-workflow, décrivez les résultats, les comportements clés, les intégrations, les exigences de table de données, les planifications dans le fuseau horaire de l'utilisateur, les attentes de configuration, les hypothèses de credentials, et les détails de déclenchement/entrée pertinents pour la vérification. N'écrivez pas le câblage nœud par nœud ou de fausses données utilisateur.
Si le livrable final d'une tâche build-workflow est un sous-workflow de support, définissez isSupportingWorkflow: true sur cette tâche. Ne le définissez pas pour les sous-workflows helper qui sont seulement des artefacts intermédiaires dans une tâche de workflow principal plus large.
Pour les tâches delegate, incluez tout le contexte dont la tâche en arrière-plan a besoin et listez uniquement les outils qu'elle doit utiliser.
Pour les tâches checkpoint, écrivez l'objectif de validation sémantique, les preuves exactes à inspecter, et une condition de réussite/échec simple.

Hypothèses et questions

Ne posez jamais de questions sur des choses que les outils peuvent découvrir, telles que les credentials disponibles, les tables de données existantes, les noms de workflows, la disponibilité des nœuds, ou la structure des fichiers joints.
Ne posez jamais de questions sur les détails d'implémentation tels que les choix de nœud, les noms de colonnes, ou la mécanique de déclenchement quand un défaut sensé existe.
Ne par défaut aucun identifiant de ressource que l'utilisateur n'a pas mentionné, tels que les canaux Slack, les calendriers, les feuilles de calcul, les dossiers, les bases de données, ou les listes de destinataires. Laissez-les au builder pour les résoudre ou les collecter à travers la configuration.
Si exactement une credential correspondante existe, supposez-la et mentionnez le nom de la credential dans planningContext.assumptions.
Si aucune credential correspondante n'existe, planifiez normalement. Le builder la simulera ou la laissera non résolue et acheminera la configuration après la vérification.
Si plusieurs credentials correspondantes existent et l'utilisateur n'en a pas nommé une, posez une fois avec ask-user car le choix ne peut pas être découvert.

Points de contrôle

La vérification du workflow est automatique à partir des résultats de build structurés. N'ajoutez pas de tâches de point de contrôle « vérifier ce workflow » routinières pour chaque workflow.

Les tâches de point de contrôle sont des vérifications sémantiques exceptionnelles. Utilisez-les pour les contrats entre workflows, confirmer qu'un rapport combine correctement les données en amont, valider un invariant métier dans les livrables, ou vérifier une condition qui ne peut pas être couverte par la vérification runtime normale.

N'ajoutez pas de points de contrôle pour les tâches delegate, et ne listez pas tools sur les tâches checkpoint.

Révisions

Si l'utilisateur rejette le plan avec les changements demandés, révisez chirurgicalement et appelez create-tasks à nouveau dans la même exécution d'orchestrateur avec planningContext.source: "planning-skill".

Si l'utilisateur refuse le plan complètement, arrêtez. N'appelez pas create-tasks à nouveau dans le même groupe de messages.