dehtiarone/sub-agents avec escalade

Sous-agents avec escalade pour Codex

Coordinateur recommandé : gpt-6.1-sol à faible effort. Conservez le modèle sélectionné du parent ; ce skill ne le change pas. L'agent principal orchestre : choisir le palier, définir les critères d'acceptation, briefrer les workers, vérifier les transferts, trier et rendre compte. Il ne modifie jamais le code de production. Partez de rapports concis (30 lignes maximum), de diffs de périmètre et de chemins de preuves ; inspectez plus de code ou exécutez des vérifications lorsque des preuves manquent, sont contestées ou insuffisantes pour le risque du palier D. Ne répétez pas mécaniquement des vérifications sur un correctif inchangé.

Les workers exécutent une seule étape assignée et ne délèguent jamais ni n'invoquent ce skill. Respectez les permissions de l'hôte et le mode de collaboration ; le mode Plan n'autorise aucune implémentation ni découverte produisant des mutations.

Paliers

Nommez le palier dans la première ligne de progression. Toute étape peut le promouvoir ; ne jamais le rétrograder. En cas de promotion, conservez les compteurs, utilisez le budget total du palier supérieur et révisez les critères pour chaque worker concerné. Pour D, élevez Découvrir/Valider au moins à l'échelon 3 ; ne baissez jamais un échelon existant. Effectuez les nouvelles découvertes requises avant toute implémentation ultérieure.

Palier	Travail	Flux	Échelon de départ
A	Modification triviale, entièrement spécifiée, à faible risque avec une vérification concrète	Implémenter ; le transfert remplace Valider	1
B	Changement clair bénéficiant d'une délégation	Implémenter → Valider	1 pour les deux
C	Bug flou ou fonctionnalité substantielle ; par défaut	Découvrir → Implémenter → Valider	1 pour tous
D	Authentification, isolation locataire, migrations, file d'attente/synchronisation, modifications de données de production	Découvrir → Implémenter → Valider	Découvrir/Valider 3 ; Implémenter 1

Étapes et vérifications

1. Critères d'acceptation - parent : définir « Fait signifie » avant l'envoi. A/B dérivent les vérifications et résultats attendus de la demande ; C/D affinent le projet après Découvrir. Implémenter et Valider reçoivent des critères identiques et la demande originale.
2. Découvrir - C/D : confirmer le périmètre ou reproduire le problème. Pas de modifications de code source ; les fichiers de reproduction/test explicitement possédés sont autorisés. Rapporter cause/périmètre avec emplacements, preuves, critères proposés et questions ouvertes. Pour une découverte en lecture seule, interdire les modifications du dépôt dans le brief et vérifier le périmètre ; n'inventez pas de paramètre de bac à sable par agent.
3. Implémenter : modifier uniquement les fichiers possédés ; rapporter les modifications, commandes, statut de sortie et travail non terminé.
4. Valider - B/C/D : un agent frais qui n'a pas implémenté vérifie le correctif intégré par rapport à la demande, aux spécifications et aux critères. Aucune modification du dépôt ni nouveau test de régression ; proposer des tests manquants pour Implémenter. Les rapports brouillon et artefacts de test normaux sont autorisés. Rapporter les preuves par critère et les zones non testées.

Conditions préalables aux tests avant de s'engager dans des commandes. Privilégiez les alternatives réalisables uniquement lorsque leur couverture est équivalente. Ne substituez jamais des tests unitaires aux preuves d'intégration, de bout en bout, visuelles ou de périphérique requises simplement pour obtenir un SUCCÈS. Incluez les vérifications bloquées requises dans le résultat final ; ne supposez pas qu'un exécuteur de test particulier peut s'exécuter dans le bac à sable. Réessayez les échecs environnementaux uniquement après un correctif concret.

Découvrir/Implémenter renvoient FAIT, PARTIEL ou BLOQUÉ. Valider renvoie SUCCÈS, ÉCHEC, BLOQUÉ ou NON CONCLUSIF. Budgets de temps par appel : A/B 10 minutes ; C/D 25 minutes. À la limite, renvoyer PARTIEL ou NON CONCLUSIF avec le travail effectué, les preuves, les vérifications en suspens et l'étape suivante.

Échelle et envoi

Échelon	Modèle	reasoning_effort
1	gpt-6-luna	medium
2	gpt-6-luna	medium
3	gpt-6.1-sol	low
4	gpt-6.1-sol	medium
5	gpt-6.1-sol	high

L'échelon 2 est une nouvelle tentative Luna avec des preuves de correction concrètes. Sol low est Light dans l'application, pas un échelon supplémentaire. Pour une omission concrète ou un brief mal lu, avancez d'un échelon ; l'échelon 2 est la seule nouvelle tentative pour omission avant le modèle plus fort. Pour un échec de raisonnement confirmé aux échelons 1 ou 2, passez directement à l'échelon 3. À l'échelon 3 ou plus, avancez d'un échelon. « Escalader » ci-dessous signifie cette règle. Arrêtez-vous lorsque le travail inadéquat épuise l'échelon 5. Les continuations productives et les échecs environnementaux corrigés n'avancent pas les échelons. Ne réessayez pas la même approche échouée sans une correction concrète ; escaladez plutôt. Cela n'interdit pas les continuations productives.

Utilisez le schéma exposé de Codex : spawn_agent avec un task_name unique, un brief complet dans message, model, reasoning_effort et fork_turns: "none" explicites là où c'est pris en charge. N'utilisez pas de fork d'historique complet pour les dérogations. Signalez les contrôles incompatibles plutôt que de modifier la configuration globale ou de les contourner avec une CLI imbriquée. Utilisez followup_task pour les continuations au même échelon et un nouveau spawn pour les changements de modèle/effort. Les appels wait/list/steering ne créent pas d'assignations supplémentaires gratuites. Interrompez les workers en retard et assurez-vous que les écritures s'arrêtent avant de continuer. Enregistrez les paramètres effectifs demandés et observables ; utilisez unavailable lorsque les valeurs effectives ne sont pas exposées. Ne substituez jamais silencieusement des modèles ou paramètres indisponibles. Conservez les chemins de preuves dans les briefs au lieu de copier les transcriptions. Les briefs de nouvelle tentative nomment la correction/hypothèse et disent continuer le correctif ou remplacer ces hunks.

Comptabilité et triage

Suivez le nombre total d'appels, d'appels par étape et d'échelon par étape/élément de travail séparément. Chaque nouvelle assignation de travail, nouvelle tentative ou continuation coûte un appel ; les messages de statut et les attentes n'en coûtent aucun. Les workers parallèles et les workers de test de base sont comptés individuellement. Lorsque c'est pris en charge, créez une entrée de liste de tâches d'exécution par assignation ou continuation envoyée ; sa mise à jour ne coûte aucun appel. Un ÉCHEC correct de Valider est une validation réussie, pas une raison d'escalader le validateur. Diagnostiquez l'échec avant de choisir une ligne.

Constatation	Action suivante	Comptabilisation comme
Travail inadéquat	Escalader l'étape responsable avec des preuves	appel + avancement/saut d'échelon
PARTIEL avec approche et progression solides	Continuer au même échelon	appel
Deuxième PARTIEL au même échelon, ou absence de preuve de progression	Escalader cette étape	appel + avancement/saut d'échelon
Mauvais diagnostic	Escalader Découvrir ; réviser le brief d'implémentation ensuite	appel + avancement/saut d'échelon (Découvrir)
Valider ÉCHEC est erroné	Le parent corrige avec des preuves enregistrées, ou escalade Valider ; ne modifiez pas Implémenter	aucun pour correction ; appel + avancement/saut d'échelon pour revalidation
Valider ÉCHEC identifie correctement une implémentation inadéquate	Escalader Implémenter, puis un nouveau Valider à son échelon actuel	appel + avancement/saut d'échelon (Implémenter), appel (Valider)
Valider expire avec des vérifications effectuées listées	Continuer à son échelon actuel sur les vérifications en suspens	appel
Échec environnemental ou prérequis manquant	Corriger dans les limites d'autorisation, puis réessayer une fois ; arrêter si non résolu	appel pour nouvelle tentative ; aucun changement d'échelon
Ambiguïté bloquante modifiant « fait » ou risque du palier D	Demander à l'utilisateur ; nommer le bloqueur	aucun

La correction parentale ne supprime pas les vérifications : l'acceptation nécessite des preuves pour chaque critère. Continuez la validation dans le même agent uniquement s'il n'a jamais implémenté et que le correctif est inchangé. Après une réparation, utilisez un nouveau validateur. Un ÉCHEC correct à l'échelon 5 n'épuise pas le validateur ; triagez l'implémentation.

Budgets : A 3 appels ; B 4 ; C/D 8. Vérifiez avant l'envoi : les appels restants doivent couvrir tous les workers proposés plus une dernière validation lorsque leur travail l'exige. La validation elle-même n'a besoin que de son propre appel. Un restant + validation finale est autorisé ; deux restants + implémentation est autorisé ; deux restants + deux implémentations ne l'est pas. Réduisez un lot uniquement si tout le travail requis tient encore. Réservez l'implémentation et la validation après la découverte. Revérifiez après promotion.

Le dernier appel autorisé peut terminer la tâche avec succès. Sinon, arrêtez-vous avant un travail non abordable, en cas d'échec au dernier échelon, ou pour des bloqueurs non résolus. N'omettez jamais silencieusement un travail requis et ne prétendez pas à l'achèvement avec une validation requise en suspens. Les choix d'implémentation ordinaires ne nécessitent pas de question à l'utilisateur ; enregistrez-les.

Instantanés et transferts

Le parent seul exécute le script d'instantané Bash/Git intégré ci-dessous. Aucun fichier compagnon n'est nécessaire. Avec umask 077, créez ${TMPDIR:-/tmp}/escalating-subagents/, puis un répertoire task.XXXXXX unique avec mktemp -d. Extrayez le bloc marqué avec cette commande, jamais en le retapant (SKILL est le chemin absolu de ce document, TASK le répertoire de la tâche) :

sed -n '/^<!-- agent-snapshot:start -->$/,/^<!-- agent-snapshot:end -->$/p' SKILL | sed '1,/^```bash$/d;/^```$/,$d' > TASK/agent-snapshot.sh

Son SHA-256 (shasum -a 256 ou sha256sum) doit être ddc6cd474ae00cb7fc7613deefb4a9f5ff959f6b641abf041f1a7e26d7d8ca95 ; une non-concordance est un bloqueur. Utilisez <task>/state séparément pour les instantanés. Ne placez pas le script dans le répertoire d'état initialement vide. Exécutez-le avec Bash, ne le sourcez jamais.

Enregistrez les chemins absolus du dépôt, de l'assistant et de l'état dans le registre parent ; transmettez-les explicitement à chaque invocation, sans compter sur l'état du shell entre les commandes. Les workers n'exécutent jamais l'assistant et ne reçoivent pas ses chemins de contrôle. Initialisez avec succès avant tout envoi ; signalez les erreurs d'initialisation et arrêtez-vous, en identifiant les bloqueurs de bac à sable uniquement lorsque les permissions en sont la cause. Les mots en majuscules ci-dessous sont des espaces réservés ; citez les chemins réels :

bash HELPER init REPO STATE
bash HELPER capture STATE base
bash HELPER capture STATE pre-1
bash HELPER capture STATE post-1
bash HELPER diff STATE pre-1 post-1 names0
bash HELPER diff STATE pre-1 post-1 stat
bash HELPER diff STATE base post-1 patch

Capturez base une fois, pre-N immédiatement avant chaque envoi/lot, et post-N après que tous ses workers et écritures sont terminés. Stockez la sortie du correctif intégré dans les preuves de travail. Les instantanés nommés sont immuables. L'état conserve les ID d'arbre et les index/objets temporaires ; la vraie base de données d'index/objets est inchangée. Les fichiers ignorés suivis et les fichiers non suivis non ignorés sont inclus. N'utilisez pas git diff HEAD comme substitut.

Les échecs de l'assistant sont des bloqueurs. Il rejette les écritures concurrentes ; ne supprimez pas un verrou à moins que son processus enregistré ne soit confirmé arrêté. Les captures interrompues non publiées ne peuvent pas remplacer les instantanés nommés. Conservez l'état jusqu'à la fin du rapport et de tout suivi prévu.

Utilisez les chemins modifiés délimités par NUL pour les vérifications de périmètre, stat pour les résumés, et le correctif intégré pour Valider. Les modifications hors périmètre sont rejetées sauf si le parent étend explicitement la propriété pour une dépendance légitime. Préservez le travail non lié ; ne réinitialisez, nettoyez, stash ou annulez jamais automatiquement.

Envoyez les workers Implémenter disjoints ensemble dans la capacité disponible. Pour chaque lot, comparez à l'union des propriétés ; les rapports fournissent une attribution individuelle, pas une preuve de paternité. Attendez la fin du lot entier avant de vérifier le périmètre ou de valider. Sérialisez les fichiers/infrastructures partagés et les rédacteurs concurrents non liés qui contamineraient les instantanés.

Vérifiez les résultats des commandes, les chemins de preuves, les emplacements cités et la pertinence de l'état des fichiers lors des transferts. Les nouvelles modifications invalident les vérifications affectées. Le travail accepté avance ; le travail rejeté retourne au triage. Suivez les commandes de longue durée jusqu'à leur terme et arrêtez les écritures en suspens avant de prendre un instantané ; le lancement en arrière-plan n'est pas une fin.

Contraintes du dépôt et briefs

Lisez les AGENTS.md applicables, les instructions ciblées, les spécifications et les directives de conception. Utilisez le gestionnaire de paquets, le verrouillage, les versions de dépendances, la migration et les politiques de documentation du dépôt. Transmettez explicitement les contraintes relatives aux données de production dans les briefs des workers concernés, y compris les exigences de données en direct et d'ajouts uniquement le cas échéant ; ne comptez pas sur les workers pour les découvrir indirectement.

Les workers ne commitent, poussent, déploient ou effectuent jamais d'écritures externes non liées. Le parent peut effectuer des actions explicitement demandées uniquement lorsque les règles du dépôt et de l'hôte le permettent.

Chaque brief comprend : tâche, palier, demande originale, chemins absolus du dépôt/instructions/preuves, modèle/effort, critères textuels, propriété, délais de commande, budget temps réel, contraintes de données de production, et « ne déléguez pas, n'invoquez pas ce skill, n'exécutez pas l'assistant d'instantané ».

• Découvrir : chemins pertinents, rapport précédent si nouvelle tentative ; ne possède rien sauf les fichiers de repro/test explicitement autorisés. Pas de modifications de code source ni d'installations. Rapporter résultat, cause/périmètre, emplacements, preuves, critères proposés, points ouverts, étape suivante.

• Implémenter : la demande originale inchangée, les critères d'acceptation textuels, la propriété, la directive « pas de tests » (sauf les nouveaux tests de passage pour les nouveaux codes ou les réparations nécessaires — le juge est le validateur, pas l'implémenteur). Rapporter les modifications, les preuves, le statut des commandes.

• Valider : le correctif intégré, les preuves de Découvrir (si applicable) et Implémenter, la demande, les critères, le résultat attendu. Produire un rapport par critère avec preuves ; signaler les zones non testées. Ne pas suggérer de nouvelles modifications de code source ; proposer de nouveaux tests pour Implémenter.

Exemple de brief

Tâche : corriger le double encodage dans writePayload (palier C)
Demande originale : [coller]
Dépôt : /home/user/repo
Instructions : /home/user/repo/AGENTS.md
Preuves : /tmp/evidence
Modèle : gpt-6.1-sol, effort raisonnement moyen
Critères d'acceptation :
- writePayload(X) produit un JSON correctement encodé pour les chaînes avec des caractères Unicode
- Tous les tests existants passent
- Aucune modification des API publiques
Propriété : src/encode.js, src/encode.test.js seulement
Délai : 120 secondes
Budget : 25 minutes
Contraintes de données de production : aucune
Règles : ne déléguez pas, n'invoquez pas ce skill, n'exécutez pas l'assistant d'instantané

Schéma d'instantané (script fourni séparément)

#!/usr/bin/env bash
# Script d'instantané pour escalating-subagents - voir SKILL.md
set -euo pipefail
# ... [contenu du script omis pour la brièveté] ...

Licence

MIT