0xVoidw/subagent-allocator

Répartiteur de sous-agents

Transforme un plan.md en un tableau de répartition exécutable : qui fait quoi, avec quel modèle, avec quel effort de réflexion, et comment escalader en cas d'échec.

Le principe pour économiser des crédits est simple : la majeure partie du travail dans un plan consiste en lecture de fichiers, recherche de code, exécution de tests et modifications selon des spécifications, ce qui ne nécessite pas les modèles les plus coûteux. Les modèles coûteux ne doivent être utilisés que là où un véritable jugement est nécessaire. Ce skill se charge de séparer ces deux catégories.

Entrées

1. Chemin du plan.md. S'il n'est pas fourni, cherche plan.md / PLAN.md / PLANS.md dans le répertoire courant. En dernier recours, demande.
2. Plateforme cible : claude (Claude Code), codex (OpenAI Codex) ou both. Si non précisé, déduit de l'environnement d'exécution ; si impossible, demande une fois.
3. Orientation (optionnelle) : économiser, équilibré (par défaut), sûr. N'affecte que l'étape 4 ci-dessous lorsqu'il y a une indécision.

Une fois la plateforme déterminée, lit le fichier de référence correspondant qui contient les noms de modèles spécifiques, les ratios de prix et les paliers d'effort :

• Claude → references/claude.md
• Codex → references/codex.md
• both → lit les deux, présente les deux configs côte à côte dans la sortie

Les noms de modèles et les prix deviennent obsolètes. Les fichiers de référence sont la seule source de vérité ; ne pas utiliser de mémoire pour les noms de modèles.

Processus

1. Lire le plan, décomposer en unités de tâches

Conserver la division en étapes du plan.md, en n'ajustant que dans deux cas :

• Séparer : une étape contient à la fois "beaucoup de lecture/recherche" et "prise de décision/modification de code". Extraire la partie lecture pour un sous-agent peu coûteux qui ne retourne qu'un résumé.
• Fusionner : plusieurs petites étapes consécutives modifient les mêmes fichiers et nécessitent le même contexte. Les fusionner en une seule tâche pour éviter de recharger le contexte plusieurs fois.

Ne pas trop décomposer. Chaque sous-agent a un coût de démarrage (relecture du contexte, rédaction des instructions de passation). Les petites tâches qui peuvent être faites en quelques minutes par l'agent principal doivent être marquées comme "exécutées directement par l'agent principal".

2. Attribuer cinq marqueurs à chaque tâche

Marqueur	Question posée	Valeurs
Clarté	Les spécifications sont-elles déjà figées, il suffit de les suivre ?	Claire / Partielle / Ouverte
Coût d'erreur	Est-ce facile de détecter et annuler une erreur ?	Faible / Moyen / Élevé
Vérifiabilité	Y a-t-il des tests, builds, linters, scripts pour juger automatiquement ?	Oui / À ajouter / Non
Volume de lecture	Combien de matériel faut-il lire avant d'agir ?	Faible / Élevé
Impact	La modification est-elle locale, entre modules, ou architecturale ?	Local / Entre modules / Architecture

Si le plan.md n'est pas clair, juger en fonction du cas le plus probable et l'indiquer dans la colonne "Hypothèses" de la sortie, sans poser de questions.

3. Mapper sur quatre paliers

Les modèles spécifiques à chaque plateforme sont dans les fichiers de référence ; ici on ne définit que les paliers :

Palier	Utilisation	Tâches typiques
T0 Léger	Claire + coût faible + résultat vérifiable d'un coup d'œil	Rechercher des fichiers, lire des logs, exécuter des tests et rapporter, classer, extraire, résumer
T1 Standard	Claire + local + vérifiable	Implémenter une fonctionnalité selon des spécifications, corriger un bug bien localisé, écrire des tests, rédiger de la documentation, reproduction d'UI
T2 Principal	Partiellement claire, ou entre modules, ou nécessitant un débogage/jugement	Fonctionnalités multi-fichiers, débogage d'un bug de cause inconnue, revue de code, intégration de résultats de sous-agents
T3 Flagship	Ouverte + architecturale, ou coût d'erreur élevé sans vérification automatique	Décisions architecturales, schémas de refactoring lourds, arbitrages entre contraintes multiples, direction de plusieurs sous-agents

Ordre de jugement : supposer d'abord T1, puis voir s'il y a une raison de descendre ou de monter.

• Raison de descendre en T0 : la tâche consiste essentiellement à "trouver et rapporter", sans produire de code à fusionner.
• Raison de monter en T2 : la clarté n'est pas "claire", ou l'impact n'est pas "local".
• Raison de monter en T3 : doit satisfaire à la fois "ouverte ou architecturale" ET "coût d'erreur élevé". Si une seule condition est remplie, utiliser T2 avec effort élevé.

Dans un plan normal, il n'y a généralement que 0 à 2 tâches T3. Si la moitié des tâches sont en T3, revenir à l'étape de décomposition : le plus souvent, la "lecture" et le "jugement" ont été mélangés.

4. Définir l'effort de réflexion

L'effort est un réglage plus fin que le changement de modèle ; il faut d'abord l'ajuster.

• Départ : toujours commencer avec la valeur par défaut du palier dans le fichier de référence.
• Vérifiabilité = Oui : conserver la valeur de départ, voire baisser d'un cran. Si le modèle peut s'auto-vérifier avec des tests, un effort élevé apporte peu de bénéfices.
• Vérifiabilité = Non ET coût d'erreur ≥ Moyen : monter d'un cran.
• Quelqu'un attend les résultats en temps réel : baisser d'un cran, priorité à la vitesse.
• Orientation = économiser : en cas d'indécision, prendre la valeur la plus basse ; sûr : prendre la valeur la plus haute.

Au-delà de high, augmenter l'effort coûte souvent presque aussi cher que de passer directement au modèle du palier supérieur avec un effort faible. L'échelle de progression est donc la suivante :

1. Ajouter d'abord un moyen de vérification (lui donner une commande de test ou de vérification exécutable)
2. Monter l'effort d'un cran, jusqu'à high au maximum
3. Passer au modèle du palier supérieur, avec l'effort de départ le plus bas de ce palier

Le T0 de Codex est une exception : son rapport qualité-prix reste excellent même à effort élevé, voir references/codex.md pour plus de détails.

5. Protection de la qualité

Économiser des crédits ne doit pas se faire au prix de reprises, qui coûtent plus cher que d'utiliser le bon modèle dès le départ. Voici les moyens de garantir que "la qualité ne se dégrade pas significativement" :

• Chaque tâche doit avoir un critère d'achèvement. Si possible, sous forme de commande (pytest tests/x, npm run build). Si aucun critère d'achèvement ne peut être écrit, la tâche monte d'un palier.
• Les modifications de code et les décisions critiques restent au-dessus de T1. T0 ne fait que lire, ou écrire ce qui n'ira pas dans la branche principale (rapports, listes).
• Après l'exécution d'un modèle bon marché, un modèle du palier supérieur examine le diff. L'examen du diff ne lit que la partie modifiée (peu de tokens), mais arrête la plupart des problèmes. Ajouter une tâche de revue indépendante à la fin de chaque phase dans le tableau de répartition.
• Les sous-agents ne retournent que des conclusions. Dans la définition du rôle, spécifier le format et la limite de longueur de la réponse (par exemple "résumé de moins de 200 mots + liste des chemins de fichiers pertinents") pour éviter que de longues sorties n'engorgent le contexte de l'agent principal.

6. Ordonnancement de l'exécution

• Les tâches indépendantes sont marquées comme parallélisables.
• Autant que possible, regrouper les tâches utilisant le même modèle, et changer de modèle aux points de coupure naturels entre les phases. Changer fréquemment de modèle en cours de route videra le cache, ce qui équivaut à repayer le coût du contexte.
• Les considérations spécifiques à chaque plateforme (appartenance du cache, seuils de majoration pour contexte long, etc.) sont dans les fichiers de référence ; les inclure dans la section "Remarques" de la sortie.

Sortie

Écrire plan.dispatch.md dans le même répertoire que le plan.md, en utilisant la structure suivante. Si les tâches sont nombreuses, le tableau conserve toutes les tâches, mais les fiches de rôle ne sont écrites que pour les tâches de sous-agents.

# Répartition des sous-agents : <Nom du plan>

Source : <chemin du plan.md>　Plateforme : <claude / codex / both>　Orientation : <économiser / équilibré / sûr>

## Aperçu

| # | Tâche | Exécutant | Palier | Modèle | Effort | Dépendances | Parallélisable |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | … | Explorateur | T0 | … | … | Aucune | Avec 2 |

Distribution des paliers : T0 ×n, T1 ×n, T2 ×n, T3 ×n
Agent principal : <modèle> / <effort>, responsable de <coordination, intégration, validation finale, etc.>

## Phases d'exécution

### Phase 1 : <Nom> (Modèle : …)
- Tâches 1, 2 en parallèle
- Revue de fin de phase : <qui révise, quoi>

## Fiches de rôle

### Tâche 1 : <Nom>
- **Rôle** : <description en une phrase, ex. "Explorateur en lecture seule : localiser toutes les occurrences de l'ancienne interface">
- **Modèle / Effort** : … / …
- **Objectif** : …
- **Entrée** : <fichiers, répertoires, messages d'erreur à lire>
- **Contraintes** : <ce qui est interdit de modifier, normes à suivre>
- **Critère d'achèvement** : <commande ou état vérifiable>
- **Format de retour** : <contenu et limite de longueur>
- **Échelle de progression** : Ajouter vérification → effort monte à … → Remplacer par … / …
- **Raison du choix** : <une phrase, en lien avec les cinq marqueurs>

## Hypothèses et remarques
- <éléments non clarifiés dans le plan.md, déduits par ce skill>
- <pièges de coût spécifiques à la plateforme>

## Économies estimées
Par rapport à une configuration "tout palier principal par défaut" : estimation grossière <ex. "environ la moitié des tâches passent en T0/T1, leur prix unitaire est divisé par 2 à 20">

Les quatre champs "Objectif, Entrée, Contraintes, Critère d'achèvement" de la fiche de rôle sont les instructions directement copiables-collables pour le sous-agent ; ils doivent être rédigés de manière à être compris indépendamment, car le sous-agent ne verra pas le reste du plan.md.

La section "Économies estimées" ne donne qu'un ordre de grandeur et la justification, sans fabriquer de pourcentage précis. La consommation réelle dépend de la tâche elle-même ; il est conseillé à l'utilisateur de comparer avec les statistiques d'utilisation après exécution et d'ajuster.

Exemple

Dans un plan.md, une étape :

3. Remplacer toutes les occurrences de oldLogger par newLogger dans le dossier utils/, en notant que certaines endroits transmettent un formateur personnalisé

Traitement : cette étape mélange "trouver tous les points d'appel" (volume de lecture élevé, lecture seule) et "remplacer et gérer les cas spéciaux de formateur" (modification de code, cas spéciaux nécessitant un jugement). Séparer en deux tâches :

#	Tâche	Exécutant	Palier	Effort	Raison
3a	Lister tous les points d'appel de oldLogger et signaler ceux avec formateur personnalisé	Explorateur	T0	Valeur de départ	Lecture seule, les oublis seront détectés par le grep de 3b
3b	Remplacer selon la liste, adapter chaque formateur un par un	Implémenteur	T1	Valeur de départ	Spécifications claires, critère d'achèvement : grep -r oldLogger utils/ vide et tests passent

S'il n'y a pas de test couvrant le comportement du formateur, l'effort de 3b monte d'un cran, et cela est mentionné dans "Hypothèses et remarques".