task-splitter

Task Splitter — exécution correcte au moindre coût

Objectif : terminer la tâche principale avec le coût total le plus bas qui satisfasse la qualité. Deux leviers : (1) router chaque morceau de travail vers le niveau le moins cher capable, (2) payer le contexte de démarrage à froid de chaque sous-agent une seule fois en regroupant le travail de même niveau dans un seul thread.

Lisez references/routing-rubric.md avant de noter et references/batch-brief-template.md avant d'écrire toute instruction de lot.

Règles strictes

• Le travail T0 ne déclenche jamais d'agent. Les étapes déterministes (install, mkdir, mv, une valeur de configuration, exécution d'un générateur) s'exécutent en ligne dans le thread principal. Un sous-agent à froid coûte plus cher que la commande.
• N'utilisez jamais subagent_type: "fork" pour les niveaux bon marché. Un fork s'exécute toujours sur le modèle parent et ignore model. Utilisez general-purpose (ou Explore pour une recherche en lecture seule) avec un model et effort explicites.
• Cette compétence autorise explicitement le réglage de effort sur chaque appel d'Agent qu'elle effectue, en utilisant le tableau des niveaux. Passez toujours à la fois model et effort.
• Vérification par scripts, pas par modèles. Les tests, lint, typecheck et build sont exécutés par le thread principal. Ne dépensez pas d'appel de modèle pour réviser du code qu'un script peut vérifier.
• Escaladez uniquement la sous-tâche en échec, d'un niveau, une fois. Après une escalade, arrêtez-vous et demandez à l'utilisateur.
• Ne regroupez jamais deux sous-tâches qui modifient le même fichier dans des lots différents de la même vague.

Tableau des niveaux (valeurs par défaut — calibrer avec le journal de routage)

Niveau	Score	S'exécute comme	Travail typique
T0	0	thread principal, shell en ligne	installer les dépendances, créer les répertoires, renommer, définir une valeur d'env/config
T1	1–3	model: haiku, effort: low	code passe-partout suivant un modèle existant, corrections de copie, câblage CRUD simple, docs, fixtures
T2	4–6	model: sonnet, effort: medium	code normal de fonctionnalité, composants, points d'accès, tests suivant les modèles existants
T3	7–8	model: sonnet, effort: high	logique multi-fichiers, gestion d'état, intégrations, bugs délicats, auth/paiements/sécurité
T4	9–10	model: opus, effort: high	architecture, conception transversale, modèle de données, débogage difficile, perf/concurrence

Pondérations de coût relatives pour l'aperçu : haiku = 1, sonnet = 3, opus = 5 ; multiplicateur d'effort low = 1, medium = 1,5, high = 2,5. T0 = ~0.

Flux de travail

Phase 0 — Capture et persistance

1. Reformulez la tâche principale en ≤10 lignes : objectif, contraintes, critères d'acceptation, stack, hors périmètre.
2. Dérivez un slug. Cherchez un registre existant dans <projet>/.claude/task-splitter/ (ls .claude/task-splitter/ 2>/dev/null). S'il correspond à cette tâche et contient des sous-tâches non terminées → reprenez-le (passez à la première phase dont le travail n'est pas fait).
3. Sinon, créez <projet>/.claude/task-splitter/<YYYY-MM-DD>-<slug>.md à partir de templates/split-ledger.md et remplissez la section Contexte. Mettez-le à jour après chaque phase. En mode planification, si l'écriture de fichiers hors du fichier de plan n'est pas autorisée, placez le contenu du registre dans le fichier de plan sous une rubrique ## Registre et écrivez le vrai fichier comme première étape T0 après approbation.

Phase 1 — Exploration légère

Lisez uniquement ce dont le découpage a besoin : manifest (package.json, pyproject, etc.), points d'entrée, les fichiers que la fonctionnalité touche, les utilitaires existants à réutiliser. Si une recherche large est nécessaire, utilisez UN agent Explore avec model: haiku, effort: low et demandez uniquement les chemins + résultats en une ligne. Enregistrez les utilitaires réutilisables et les chemins exacts des fichiers dans le registre — ils deviennent les paquets de contexte qui empêchent les agents bon marché de ré-explorer.

Phase 2 — Découpage

Divisez le travail en sous-tâches atomiques. Chaque sous-tâche a : id (S1, S2…), goal (une phrase), files (chemins exacts, nouveaux ou existants), depends_on (ids), done_check (une commande comme pnpm test foo ou un critère précis), type (tag court : install, scaffold, component, endpoint, test, migration, refactor, config, docs, debug, design…). Atomique = un agent peut la terminer sans décisions qui appartiennent à une autre sous-tâche. Extrayez les décisions de conception dans leur propre sous-tâche précoce (souvent T4) pour que les sous-tâches suivantes soient mécaniques et bon marché.

Phase 3 — Notation et routage

Notez chaque sous-tâche avec la grille à 5 dimensions dans references/routing-rubric.md (ambiguïté, profondeur de raisonnement, portée, contexte nécessaire, nouveauté ; 0–2 chacune), appliquez les règles de dérogation, puis mappez le score → niveau. Ensuite vérifiez ~/.claude/task-splitter/routing-log.md (s'il existe) : si un type a été escaladé dans ≥2 de ses 3 dernières exécutions à un niveau, commencez-le un niveau plus haut ; s'il a réussi du premier coup ≥3 fois de suite à un niveau inférieur à celui que vous avez choisi, envisagez de baisser d'un niveau.

Phase 4 — Regroupement en lots

1. Construisez les vagues de dépendances : vague 1 = sous-tâches sans dépendances non satisfaites ; vague N = celles dont les dépendances sont toutes dans les vagues précédentes.
2. Dans chaque vague, regroupez par (model, effort), puis par zone de code (même dossier de fonctionnalité / module) pour qu'un agent charge les fichiers connexes une seule fois.
3. Limites par lot : ≤6 sous-tâches ou une zone cohérente ; aucun fichier édité par deux lots dans la même vague (déplacez la sous-tâche en conflit dans le même lot ou la vague suivante).
4. Fusionnez les très petits lots : une sous-tâche T1 isolée rejoint un autre lot T1 dans la même vague s'il existe ; une sous-tâche T1 isolée presque mécanique peut être faite en ligne à la place.
5. Les sous-tâches T0 sont regroupées en une seule étape en ligne au début de leur vague.

Phase 5 — Aperçu des coûts (porte d'approbation)

Écrivez dans le fichier de plan (ou montrez à l'utilisateur, hors mode planification) :

| Vague | Lot | Modèle / effort | Sous-tâches | Coût estimé |
|-------|-----|-----------------|-------------|-------------|
| 1     | en ligne | main / shell | S1, S2 | ~0 |
| 1     | B1 | haiku / low | S3, S4 | 2 |
| 1     | B2 | sonnet / medium | S5 | 4,5 |
| 2     | B3 | opus / high | S6 | 12,5 |
Total ≈ 19 unités (base tout-opus/high ≈ 75 unités → ~75 % moins cher)

Coût estimé = nombre de sous-tâches × poids du modèle × multiplicateur d'effort. Incluez la base tout-opus/high pour que l'économie soit visible. En mode planification, terminez par ExitPlanMode ; n'exécutez pas avant approbation.

Phase 6 — Exécution

Pour chaque vague, dans l'ordre :

1. Exécutez l'étape en ligne T0 de la vague.
2. Lancez tous les lots de la vague en UN SEUL message (appels d'Agent parallèles) : Agent(subagent_type: "general-purpose", model: <modèle du niveau>, effort: <effort du niveau>, description: "<vague>/<lot>: <court>", prompt: <bref>). Construisez chaque instruction à partir de references/batch-brief-template.md. Le préambule commun doit être identique octet par octet pour tous les lots (compatible avec le cache de prompt) — placez le contenu variable après.
3. Attendez que chaque lot de la vague ait rapporté avant de commencer la vague suivante. N'écrivez jamais ou ne devinez pas le résultat d'un agent en attente.
4. Mettez à jour le registre avec le statut de chaque lot et les fichiers rapportés.

Phase 7 — Vérification et escalade

1. Après chaque vague, le thread principal exécute les commandes done_check des sous-tâches plus les vérifications globales bon marché du projet (typecheck / lint / tests affectés).
2. Une sous-tâche en échec est réexécutée seule (ou avec d'autres échecs du nouveau même niveau) à un niveau supérieur, avec la sortie en échec et le rapport de l'agent précédent joints.
3. Maximum une escalade par sous-tâche. Si elle échoue encore, arrêtez-vous et demandez à l'utilisateur avec un court diagnostic. Les échecs T4 vont directement à l'utilisateur.

Phase 8 — Enregistrement et apprentissage

1. Marquez le registre comme complet : niveau final de chaque sous-tâche, réussi/escaladé, fichiers modifiés.
2. Ajoutez une ligne par sous-tâche à ~/.claude/task-splitter/routing-log.md (créez le dossier/fichier s'il manque ; jamais à l'intérieur du dépôt git de la compétence) : YYYY-MM-DD | <projet> | <type> | <niveau de départ> | <niveau final> | premier-passage|escaladé|échoué
3. Rapportez à l'utilisateur en ≤10 lignes : ce qui a été fait, unités de coût final vs base de référence, toute escalade, tout ce qui reste ouvert.

Conventions de sortie

• Gardez le thread principal léger : les agents renvoient des rapports courts, pas le contenu des fichiers.
• Donnez à l'utilisateur des tableaux, pas de la prose, pour le découpage et l'aperçu des coûts.
• Si toute la tâche a un score ≤3 total, ou a ≤2 sous-tâches, dites-le et faites-la directement — la découper coûterait plus que ce qu'elle économise.