conductor — boucle autonome de livraison d'un item de travail
Ce skill est pleinement défini et opérationnel : il ne s'agit pas d'un squelette, mais d'un protocole détaillé destiné à piloter un item de travail unique (correction de bug, ajustement d'ergonomie, petite fonctionnalité) depuis la planification jusqu'à l'ouverture d'une pull request gatée, sans jamais solliciter d'input humain en cours de boucle. Il est utilisé directement par Claude dans le contexte du repo crbnos/carbon, un ERP open source pour l'industrie manufacturière.
Cycle de travail
Le conductor organise le travail en plusieurs étapes enchaînées : création d'un worktree isolé sur origin/main, binding du work item dans un fichier .loop.md (avec critères d'acceptation explicites), décomposition en tâches ordonnées, puis répétition du cycle doer → checkpoint/gates → judge subagent → décision/ledger jusqu'à ce que tous les critères soient satisfaits et prouvables. Chaque itération est consignée dans un fichier ledger JSONL via @carbon/harness.
Protocole de décision autonome
Le skill ne pose jamais de question en cours de boucle : toute ambiguïté est résolue par ordre de priorité (précédent dans le codebase, consensus de recherche, recommandation de l'agent), puis consignée dans la section « Assumed decisions » du corps de la PR pour revue humaine. Certaines décisions restent hors périmètre autonome (changements de schéma critiques, modifications d'auth/RBAC, dépendances de production nouvelles) : le skill se déclare alors BLOCKED et s'arrête proprement sans supprimer le travail déjà commité.
Gates et preuve de comportement
Avant de conclure chaque tâche, le conductor enchaîne les gates obligatoires : formatage Biome, suite de gates @carbon/harness (lint, conformance, détection de clobber), typecheck par package touché, puis une preuve de comportement choisie selon le principe du « moyen le plus léger suffisant » — test unitaire/intégration, vérification visuelle via browser agent, ou preuve CLI. Une preuve non atteignable n'invalide pas le travail déjà approuvé par le judge : la PR est ouverte en draft avec le label agent:needs-verification.
Résultat : une PR gatée, jamais mergée
L'issue finale est toujours une pull request ouverte avec gh pr create, jamais mergée automatiquement. Le corps de la PR documente la justification de design, la preuve par critère d'acceptation, le résumé du ledger et les questions ouvertes. Si tous les critères sont prouvés, la PR passe en « ready for review » avec une demande de revue explicite ; sinon elle reste en draft. Le skill s'intègre également comme inner loop dispatchable par un orchestrateur externe via cron, tel que décrit dans .ai/docs/outer-loop.md.