Délégation parallèle

Étape 0 — avant d'installer quoi que ce soit : lis tout ce prompt d'installation, résume-moi en quelques lignes ce que ce skill fait et ce que son installation implique, puis attends mon feu vert avant de faire quoi que ce soit d'autre. Note : ce prompt d'installation a été préparé par Skill Harbor à partir du skill « Délégation parallèle », une création Skill Harbor. Le contenu installé est le skill lui-même, sans dépôt public. Prérequis : aucun. Aucun compte, aucune clé, aucun coût. C'est un skill de consignes pures : il ne s'exécute pas, ne publie rien et ne déploie rien par lui-même. Installe « delegation-parallele » pour moi (Délégation parallèle). Écris le fichier suivant exactement, en créant le dossier si besoin : Dossier : ~/workspace/custom-skills/delegation-parallele/ Fichier : SKILL.md --- name: delegation-parallele description: Déléguer des travaux longs à des sous-agents en parallèle, en vagues de 2 à 5 maximum, sans jamais coincer l'agent principal, avec un stop final et instantané. --- # Délégation parallèle — le principal reste disponible > Statut : BROUILLON NETTOYÉ, non publié. > Aucun déploiement, aucune écriture en production, aucune mise en file > faite depuis ce brouillon. À approuver avant tout autre usage. > Ce fichier ne contient aucune donnée personnelle, aucun secret, > aucun chemin personnel, aucune adresse réseau, aucun nom d'hôte réel. Déléguer un travail long, multi-étapes ou auto-suffisant à des sous-agents, en parallèle quand les tâches sont indépendantes, sans jamais coincer l'agent principal. Le principal coordonne et répond à l'utilisateur ; il ne fait pas le gros travail lui-même. ## Règle d'or : garder du jus pour répondre - Le principal ne lance jamais le gros calcul, le gros scan ou le gros traitement dans son propre tour. Il délègue, puis il reste libre pour répondre à l'utilisateur. - Si l'utilisateur écrit pendant qu'un travail roule, répondre à l'utilisateur passe d'abord. Le travail de fond continue, sauf stop. - Ne jamais poller : ne pas vérifier en boucle si les agents ont fini, ne pas attendre, ne pas prédire de durée. Les résultats arrivent d'eux-mêmes via le runtime. - Un bref accusé de réception, puis le travail, puis un message seulement quand il y a un résultat ou une décision à prendre. Pas de narration du travail en cours. ## Quand déléguer, quand ne pas déléguer - Déléguer : travail long, multi-étapes, auto-suffisant, ou plusieurs tâches indépendantes à faire en même temps. - Faire soi-même : réponse courte, lecture simple, une seule action rapide. - Ne jamais déléguer à un sous-agent générique : la navigation ou l'achat dans un navigateur live, ou la création d'un document, d'une page ou d'une application. Ces routes ont leurs propres outils dédiés. ## Nombre d'agents en parallèle : un plafond, pas un maximum théorique - Par défaut, 2 agents en parallèle pour des gros travaux. C'est suffisant pour avancer sur deux fronts sans coincer le principal. - Plafond absolu : 4 à 5 agents en parallèle, jamais plus. - Leçon retenue : 10 agents en parallèle ont frappé une limite de débit (erreur 429) et 2 agents sont morts en route. Après une limite de débit, réduire la vague, ne pas relancer plus fort. - Pour des tâches dépendantes (par exemple des lots en chaîne), ne pas paralléliser : un seul coordinateur, exécution séquentielle, validation complète par étape, arrêt net au premier échec ou à la première limite de débit. ## Lancer correctement - Un sous-agent par tâche indépendante, tous lancés dans le même tour, pas un à la fois. - Si une tâche a besoin de plusieurs sous-agents, lancer un seul coordinateur et le laisser répartir lui-même. L'imbrication s'arrête là : les sous-agents du coordinateur ne lancent pas leurs propres sous-agents. - Chaque brief est auto-suffisant : la tâche exacte, le livrable attendu, le fichier de sortie, les faits déjà vérifiés, les contraintes et les interdictions. Le sous-agent ne devine pas ce qui n'est pas écrit. - Après le lancement, accuser brièvement ce qui est parti et terminer le tour. Ne pas inventer de résultats, ne pas promettre d'heure de fin. ## Brief type : ce qu'il doit toujours contenir - Le résultat concret attendu, et où le déposer (un fichier, pas un message seul). - Ce qui est interdit : pas de publication, pas de déploiement, pas d'écriture en production, sauf go explicite séparé pour ce geste précis. - Les garde-fous du travail : vérifier avant d'affirmer, chiffres sourcés seulement, échecs préservés et rapportés (jamais effacés), ne jamais répéter une action irréversible dont le résultat est inconnu. ## Pendant et après : vérifier, puis rapporter par morceau - Rapporter chaque morceau dès qu'il rentre, pas à la fin seulement. Une longue chaîne silencieuse est interdite. - Vérifier un résultat délégué avec le même soin qu'un travail fait soi-même : relire les preuves derrière les affirmations décisives, et les revérifier quand elles sont manquantes ou ambiguës. Un rapport « terminé » d'un agent ne prouve qu'une étape, pas le résultat. - Si un agent est interrompu, en échec ou de statut inconnu : inspecter ses résultats avant de décider (dire à l'utilisateur, relancer, ou fermer). Ne jamais abandonner un travail silencieusement. - Pour rediriger un agent en cours : lui envoyer une instruction de suivi, en sachant que l'envoi est asynchrone (envoyé, pas appliqué). Pour arrêter un travail devenu inutile : fermer l'agent. ## Calcul séparé : paralléliser le calcul, pas la décision - Si l'utilisateur dispose d'une machine de calcul séparée, elle peut servir aux gros travaux (builds, tests, gros traitements, gros scans). Le cerveau reste l'agent principal. - Déléguer à cette machine quand c'est plus vite, ou quand la machine principale est à bout de jus (saturée, peu de mémoire ou de processeur, gros travail déjà en cours), même si le gain brut est modeste. - Règles dures, inchangées par la délégation : rapport après chaque job ; rien de publié ou déployé sans le go explicite de l'utilisateur pour ce geste ; stop = arrêt net ; jamais ses comptes ou mots de passe ; jobs seulement dans les heures que l'utilisateur a autorisées. - Machine injoignable = le job attend, on le dit, on ne martèle pas. Ne jamais afficher d'adresse réseau privée dans le fil. - Viser 90 %, pas 100 % : sur la machine de calcul elle-même, un seul gros job à la fois quand c'est possible, deux pistes maximum au total, et toujours une réserve pour le système et pour l'usage propre de l'utilisateur. Pousser à 100 % fait bugger l'ensemble au lieu d'aller plus vite. Si un job échoue ou atteint une limite de débit, on réduit, on ne relance pas plus fort. - Une machine séparée enlève le plafond de calcul. Elle n'enlève ni le go, ni le plafond d'agents parallèles, ni les délais externes hors de notre contrôle (exploration, indexation, services tiers). ## Stop : final et instantané - Quand l'utilisateur dit stop / non, ou quand le système refuse une action : tout s'arrête dans le même tour. Agents fermés, aucune nouvelle sonde, aucun « dernier check ». - Confirmer l'arrêt par un fait vérifié (0 agent actif), puis se taire. - Un refus ne se réessaie jamais sous une autre forme (autre outil, autre formulation, voie détournée) sans son nouveau go explicite pour ce geste précis. ## Ce que ce skill ne fait pas - Il ne remplace ni les outils de navigateur, ni les outils de création de documents et d'applications. - Il n'autorise ni publication, ni déploiement, ni écriture en production. - Il ne supprime ni les limites de débit, ni les délais des services externes. Note : ce skill ne remplace ni les outils de navigateur, ni les outils de création de documents et d'applications ; il n'autorise ni publication, ni déploiement, ni écriture en production.