spawn

Présentation du spawn skill

Ce que fait spawn

spawn est un skill AgentHub qui lance plusieurs agents de codage en parallèle sur la même tâche de session. Au lieu de demander à un seul assistant de résoudre un problème de façon séquentielle, le spawn skill crée N sous-agents dans des git worktrees isolés afin qu’ils puissent tester des stratégies différentes sans écraser leurs changements respectifs.

Utilisez-le lorsque vous disposez déjà d’une session AgentHub initialisée et que vous souhaitez explorer plusieurs pistes en parallèle pour de l’implémentation, du refactoring, des tests, de l’optimisation ou de la correction de bugs.

Cas d’usage idéal pour l’orchestration d’agents

spawn for Agent Orchestration est particulièrement utile lorsqu’une tâche peut être abordée par plusieurs solutions crédibles. Il convient aux équipes comme aux développeurs solo qui veulent laisser des agents explorer des alternatives, comparer les résultats et réduire le risque de se fixer trop tôt sur la première implémentation.

Les bons candidats incluent l’optimisation des performances, les gros refactorings, l’investigation de bugs intermittents, le manque de couverture de tests et les changements de code où des approches indépendantes peuvent faire apparaître des compromis utiles.

Ce qui distingue ce spawn skill

Son principal avantage tient à la combinaison de l’isolation et d’une compétition structurée. Chaque agent travaille dans son propre git worktree, ce qui sépare les modifications parallèles et rend la comparaison ultérieure plus sûre. Le skill prend aussi en charge des templates comme optimizer, refactorer, test-writer et bug-fixer, afin que les prompts de délégation correspondent au type de tâche d’ingénierie au lieu de se limiter à une consigne générique du type « résous ce problème ».

Points à considérer avant adoption

Ce skill suppose que vous utilisez déjà le workflow AgentHub environnant. Ce n’est pas un package autonome que l’on peut simplement lancer depuis n’importe quel dépôt sans préparation. Le chemin du dépôt ne contient que SKILL.md, les utilisateurs doivent donc s’attendre à ce que la définition du skill dépende de conventions et de références AgentHub adjacentes, notamment la configuration de session et des fichiers de templates situés en dehors du dossier du skill.

Comment utiliser le spawn skill

Contexte d’installation de spawn

Installez le skill depuis le dépôt source avec :

npx skills add alirezarezvani/claude-skills --skill spawn

Après l’installation, vérifiez que votre environnement prend en charge les commandes AgentHub et qu’une session a déjà été initialisée. La commande exposée par le skill est :

/hub:spawn

La décision d’installer spawn doit se fonder sur votre besoin réel d’agents parallèles coordonnés, et non sur l’envie d’ajouter un simple raccourci de prompt. Si votre workflow n’utilise pas les git worktrees ni l’orchestration basée sur des sessions, examinez la configuration AgentHub plus large avant de vous appuyer sur ce skill.

Utilisation de base de spawn

Les formes de commande courantes sont :

/hub:spawn
/hub:spawn 20260317-143022
/hub:spawn --template optimizer
/hub:spawn --template refactorer

Utilisez /hub:spawn pour la session la plus récente. Indiquez un ID de session lorsque vous devez cibler une session AgentHub précise. Ajoutez --template <name> lorsque la tâche bénéficie d’un mode opératoire spécialisé.

Les intentions de templates prises en charge par le skill incluent :

• optimizer : cycles répétés modifier/évaluer/conserver ou rejeter
• refactorer : restructurer, tester et itérer jusqu’à obtenir un état valide
• test-writer : ajouter des tests et mesurer l’amélioration de la couverture
• bug-fixer : reproduire, diagnostiquer, corriger et vérifier

Entrées qui améliorent les résultats des agents

Un bon usage de spawn commence avant la commande : la tâche de session doit être assez précise pour permettre à plusieurs agents d’agir indépendamment puis de comparer leurs résultats. Incluez les fichiers cibles, les critères d’acceptation, les commandes de test, les contraintes et ce que signifie « mieux » dans ce contexte.

Objectif de session trop vague :

Improve the API code.

Objectif de session plus solide :

Refactor the user lookup API to reduce duplicate database calls without changing response shape.
Focus on src/api/users.ts and src/services/user-cache.ts.
Run npm test -- users and npm run lint.
Preserve public types. Prefer minimal changes unless an agent can prove a cleaner design with tests.

Cela donne aux agents générés une cible commune tout en leur laissant la possibilité d’essayer des stratégies différentes.

Fichiers à lire avant l’exécution

Commencez par SKILL.md dans engineering/agenthub/skills/spawn. Examinez ensuite les ressources AgentHub voisines référencées par le skill, en particulier toute documentation de configuration de session et agent-templates.md s’il est disponible dans le dépôt installé. Les points les plus importants à vérifier sont la façon dont les sessions sont nommées, la manière dont le nombre N d’agents est choisi, l’emplacement de création des worktrees et le processus prévu pour comparer les résultats finaux ou sélectionner ce qui sera fusionné.

FAQ du spawn skill

Quand utiliser spawn plutôt qu’un prompt classique ?

Utilisez spawn lorsque l’exploration parallèle apporte une vraie valeur. Un prompt classique suffit généralement pour de petites modifications, des changements de documentation ou des tâches dont la solution est évidente. Le spawn skill est plus adapté lorsque différentes stratégies d’implémentation, conceptions de tests ou hypothèses de débogage peuvent mener à des résultats réellement distincts.

spawn est-il adapté aux débutants ?

Il n’est adapté aux débutants que si vous comprenez déjà le workflow AgentHub environnant et le fonctionnement de base des git worktrees. La commande elle-même est simple, mais le modèle opérationnel est plus avancé : plusieurs agents produiront des changements séparés qu’il faudra relire, tester et sélectionner.

Qu’est-ce qui peut empêcher une bonne utilisation de spawn ?

Les principaux blocages sont une session AgentHub non initialisée, une définition de tâche floue, l’absence de commandes de test et des dépôts qui ne se prêtent pas à des modifications parallèles dans des worktrees. Autre limite : le dossier du skill est minimal ; le contexte d’orchestration utile se trouve dans le système AgentHub plus large. Il ne faut donc pas l’évaluer comme un outil entièrement autonome.

Quand spawn est-il un mauvais choix ?

Évitez spawn pour la gestion de secrets, les opérations de production irréversibles, les minuscules corrections d’une ligne ou les tâches où la duplication de l’effort des agents crée plus de bruit que d’enseignements. C’est aussi un mauvais choix lorsque vous ne pouvez pas exécuter de tests ni comparer les résultats, car la valeur des agents parallèles dépend d’une sélection fondée sur des preuves.

Comment améliorer le spawn skill

Rendre les prompts spawn plus comparables

Pour obtenir de meilleurs résultats avec spawn, définissez des métriques de réussite que chaque agent peut optimiser. De bons critères de comparaison incluent des tests qui passent, un temps d’exécution réduit, une taille de diff plus faible, des frontières d’API plus claires, une meilleure couverture ou des preuves de reproduction du bug. Sans critères partagés, les résultats parallèles deviennent difficiles à juger.

Attribuer volontairement des stratégies diverses

Les indications de templates du skill sont les plus efficaces lorsque chaque agent reçoit une stratégie différente. Pour une correction de bug, un agent peut partir de la reproduction, un autre de l’historique git récent et un autre de tests sur les cas limites. Pour une optimisation, l’un peut réduire les allocations, un autre mettre en cache et un autre modifier la complexité algorithmique. La diversité est précisément l’intérêt du spawn skill.

Éviter les modes d’échec courants

Les échecs fréquents consistent à lancer des agents sur des objectifs vagues, à laisser tous les agents suivre le même plan, à sauter la vérification ou à fusionner la solution qui semble la plus volumineuse plutôt que celle qui est la mieux étayée. Gardez une tâche bien bornée, exigez des commandes de test et demandez aux agents de résumer leur approche, leurs compromis, les fichiers modifiés et les résultats de vérification.

Itérer après la première exécution de spawn

Après la première exécution, comparez les worktrees avant de fusionner. Conservez le meilleur candidat, écartez les branches faibles ou lancez une deuxième vague de spawn en exploitant ce que vous avez appris. Une instruction de suivi utile serait :

Use the best result from agent 2 as the baseline.
Spawn new agents to improve reliability and reduce diff size.
All agents must preserve the public API and run the same test command.

Cela transforme spawn : d’une compétition ponctuelle, il devient une boucle pratique d’orchestration d’agents.