team-composition-patterns

Vue d’ensemble de la skill team-composition-patterns

team-composition-patterns est une skill de décision pour concevoir des équipes multi‑agents dans Claude Code Agent Teams, couvrant les heuristiques de taille d’équipe, la sélection de subagent_type et les choix de mode d’affichage. Elle convient surtout aux builders qui veulent des configurations d’équipe répétables pour la revue, le débogage ou la livraison de fonctionnalités, plutôt que des prompts ad hoc du type « créer quelques agents ».

Ce que la skill team-composition-patterns vous aide à décider

Elle lève trois freins à l’adoption : combien d’agents utiliser, quel subagent_type convient à chaque rôle, et quel mode d’affichage fonctionne dans votre environnement (tmux, iTerm2, in‑process).

Scénarios idéaux et résultats attendus

Utilisez‑la quand vous avez besoin d’une composition d’équipe cohérente sur des tâches comme la revue de code, l’investigation de bugs ou l’implémentation de fonctionnalités, et quand vous voulez des équipes préréglées réutilisables plutôt que de repenser les rôles à chaque fois.

Différenciateurs vs prompts génériques

Contrairement aux prompts génériques « créer une équipe », la skill formalise des heuristiques de taille, des configurations préréglées et une matrice de décision pour la sélection de subagent_type liée aux capacités des agents.

Quand ce n’est pas adapté

Si vous n’utilisez pas Claude Code Agent Teams ou si vous n’avez besoin que d’un seul assistant pour des tâches simples, cette skill ajoute une surcharge sans bénéfice clair.

Comment utiliser la skill team-composition-patterns

Installer team-composition-patterns et point d’entrée

Installez la skill avec : npx skills add https://github.com/wshobson/agents --skill team-composition-patterns. Le guidage principal se trouve dans plugins/agent-teams/skills/team-composition-patterns/SKILL.md.

Lisez d’abord ces fichiers pour décider d’adopter

Commencez par SKILL.md, puis lisez references/agent-type-selection.md pour la matrice de décision subagent_type et references/preset-teams.md pour les équipes prêtes à l’emploi et les modèles de tâches.

Entrées attendues par la skill

Fournissez le type de tâche (review/debug/feature/migration), le niveau de complexité, les contraintes (CI vs local) et si les agents ont besoin d’accès en écriture. Ces éléments mappent directement la taille d’équipe et les choix de subagent_type.

Transformer un objectif flou en prompt solide

Faible : « créer une équipe pour revoir cette PR ».
Solide : « Review 6-file diff touching auth and caching; prioritize security and performance; local dev; need file:line findings and fixes. » Cela permet à la skill de choisir un preset de revue et les dimensions du reviewer.

Utiliser les heuristiques de taille d’équipe pour éviter le sur/sous‑dimensionnement

Faites correspondre la complexité de la tâche à la taille d’équipe : simple (1–2), modérée (2–3), complexe (3–4+). Les équipes plus grandes sont utiles quand plusieurs dimensions comptent (sécurité + performance + architecture), pas seulement un volume de code élevé.

Utiliser la matrice de décision des types d’agents

Appuyez‑vous sur references/agent-type-selection.md pour choisir le subagent_type. Exemple : code review → agent-teams:team-reviewer ; bug investigation → agent-teams:team-debugger ; exploration d’architecture sans modifications → Plan ou Explore.

Appliquer d’abord les compositions d’équipe préréglées

Les définitions d’équipes prédéfinies (review/debug) sont la voie la plus rapide vers la valeur. Elles incluent les rôles des membres, les axes de focus et des modèles de tâches structurés pour que chaque agent ait une dimension claire et un format de sortie.

Choisir le mode d’affichage selon l’environnement

Si vous avez besoin de sorties concurrentes multiples et que vous pouvez gérer des panneaux de terminal, tmux est recommandé. Pour des configurations plus légères, iTerm2 ou l’affichage in‑process réduisent la friction.

Workflow suggéré pour l’usage de team-composition-patterns

1. Classer la tâche et la complexité.
2. Sélectionner une équipe préréglée ou une équipe personnalisée selon les dimensions.
3. Assigner un subagent_type pour chaque rôle.
4. Choisir le mode d’affichage adapté à votre environnement.
5. Fournir un modèle de tâche structuré à chaque coéquipier.

FAQ sur la skill team-composition-patterns

La skill team-composition-patterns est‑elle réservée à Claude Code Agent Teams ?

Oui. Elle est conçue autour des concepts d’Agent Teams comme subagent_type et les modes d’affichage. Sans cet environnement, les recommandations sont moins actionnables.

En quoi est‑ce différent d’un prompt « créer une équipe » classique ?

Elle fournit des règles de décision pour la taille d’équipe, une matrice pour la sélection des types d’agents, et des équipes préréglées avec des modèles de tâches — des éléments qu’un prompt générique ne propose généralement pas.

Est‑ce adapté aux débutants ?

Oui, si vous suivez les équipes préréglées. La matrice de décision peut sembler dense, mais elle évite des erreurs courantes comme donner des droits d’écriture à un agent d’exploration.

Quand faut‑il éviter de l’utiliser ?

Évitez‑la pour des tâches ponctuelles à faible risque où un seul agent généraliste suffit. La coordination peut coûter plus qu’elle ne rapporte.

Est‑ce que ça prend en charge des workflows personnalisés comme les migrations ou les audits ?

Oui. La skill couvre explicitement les workflows non standards ; vous composez une équipe sur mesure en combinant les dimensions et en sélectionnant les rôles subagent_type appropriés.

Comment améliorer la skill team-composition-patterns

Donner des dimensions de tâche plus claires pour mieux concevoir l’équipe

Spécifiez les dimensions de revue (sécurité, performance, architecture, tests). Des dimensions claires permettent à la skill de mapper vers des rôles de reviewer préréglés et de réduire les chevauchements.

Éviter les modes d’échec courants

Mode d’échec : choisir le mauvais subagent_type (par ex. Plan pour une tâche qui exige des modifications). Corrigez‑le en précisant si l’agent doit écrire des fichiers et en utilisant la matrice de décision.

Utiliser un contexte d’entrée plus solide pour améliorer les résultats

Incluez des indicateurs de périmètre comme « multi-file change », « cross-cutting concern » ou « CI-only environment ». Ils modifient la taille d’équipe recommandée et le mode d’affichage.

Itérer après la première suggestion d’équipe

Si les résultats paraissent superficiels, ajoutez une dimension manquante (par ex. accessibilité), ou augmentez la taille d’équipe d’un agent. Si les réponses sont redondantes, réduisez la taille d’équipe ou resserrez le périmètre.

Créer un modèle réutilisable pour votre organisation

Adaptez les modèles de tâches préréglées dans references/preset-teams.md aux conventions de votre repo (file paths, output format, severity levels). Cela transforme le guide team-composition-patterns en workflow interne fiable.

Utiliser team-composition-patterns pour les décisions d’orchestration d’agents

Quand vous coordonnez plusieurs tâches en parallèle, utilisez la skill pour standardiser les rôles et capacités, en assurant le bon mélange d’agents reviewer, debugger, implementer et lead pour chaque flux.