Skill d'orchestration

Ce skill est destiné à un orchestrateur (généralement un agent preset Admin) qui coordonne d'autres agents et humains tout au long du cycle de vie AI-DLC au lieu de faire tout le travail lui-même. L'orchestrateur décompose le travail, confie chaque morceau à un propriétaire choisi, lance des relecteurs indépendants comme portes de qualité, et contrôle les portes d'approbation/vérification appartenant aux humains — mais ne déploie jamais seul.

Espace de noms des outils sous OpenClaw. Les noms d'outils nus ci-dessous (par ex. chorus_pm_assign_idea) sont la forme lisible ; le nom appelable réel est préfixé par chorus__ (chorus__chorus_pm_assign_idea). Voir la remarque sur l'espace de noms dans le skill chorus principal.

Il complète les autres skills plutôt que de les remplacer :

• /yolo — un agent pilote tout le pipeline en solo. L'orchestration est l'inverse : plusieurs agents, chacun possédant une partie, coordonnés par toi.
• /idea, /proposal, /develop, /review, /quick-dev — une étape unique que tu exécutes toi-même. L'orchestration est la couche au-dessus : tu décides qui exécute chaque étape.

Quand utiliser ce skill

Utilise-le quand plus d'un agent (ou agent + humain) va toucher au travail et que quelqu'un doit les maintenir cohérents :

• Tu possèdes un thème / épique / idée conteneur qui se décompose en plusieurs idées enfants indépendantes, et tu veux confier chaque enfant à un travailleur spécifique (cas motivant : un propriétaire de thème donne un enfant à Codex, un autre à un agent Claude dev, un autre à un humain).
• Une proposition approuvée a un DAG de tâches et tu veux plusieurs agents développeurs travaillant les tâches non bloquées en vagues parallèles.
• Tu as besoin d'une relecture adversariale indépendante de la proposition / tâche / fonctionnalité de quelqu'un d'autre avant qu'elle progresse.
• Tu es le propriétaire responsable et tu dois maintenir un assignataire responsable par idée tandis que le travail se déploie.

Prérequis : déléguer des idées nécessite idea:admin ; déléguer des tâches nécessite proposal:write. Exécute d'abord chorus_checkin() pour confirmer ton ensemble de permissions.

Primitives de délégation

Assigner une idée — chorus_pm_assign_idea (idea:admin)

Confie une idée entière à un agent ou utilisateur choisi. Paramètres :

Comportement que tu dois comprendre :

• L'assignataire est réveillé et progresse à partir de l'étape actuelle de l'idée — il ne re-réclame PAS. Si l'idée est open elle devient elaborating ; tout autre statut est préservé. L'assignataire reprend où l'idée est déjà (élaboration, prête-pour-proposition, etc.).
• Les cibles agent doivent tenir idea:write (via un preset comme pm_agent/admin_agent, ou une permission explicite) ou l'appel est rejeté. Les cibles utilisateur doivent être dans ta société. instanceUuid est rejeté pour les cibles utilisateur.
• Prise de contrôle silencieuse. Réassigner une idée déjà possédée déplace simplement la propriété au nouvel assignataire — il y a un propriétaire à la fois, pas d'invite de confirmation. Utilise ceci intentionnellement, pas par accident.

Assigner une tâche — chorus_pm_assign_task (proposal:write)

Confie une tâche unique à un agent développeur. Paramètres : taskUuid, agentUuid (doit tenir task:write), instanceUuid optionnel. La tâche doit être open ou assigned. L'assignataire est réveillé pour l'exécuter. Utilise ceci pour distribuer les tâches d'une proposition approuvée.

Dériver des idées enfants et les déployer

Le cas de décomposition de thème, de bout en bout :

1. Lis l'idée conteneur/thème et son contexte (chorus_get_idea, chorus_get_documents, chorus_get_comments).
2. Pour chaque tranche indépendante, crée une idée enfant avec chorus_pm_create_idea (relie-la au parent dans le corps / via references[]).
3. Assigne chaque enfant à un propriétaire distinct avec chorus_pm_assign_idea — par ex. un enfant à Codex, un à un agent Claude dev, un à un humain. Chaque enfant a maintenant son propre propriétaire unique et progresse indépendamment.
4. @mentionne chaque assignataire et le propriétaire du thème pour que la délégation soit visible.

Relecture indépendante comme porte adversariale

Chorus fournit trois skills de relecteur en lecture seule. En tant qu'orchestrateur tu les exécutes aux trois portes et agis selon le jugement — c'est ton principal levier de qualité quand tu n'écris pas toi-même le code.

Génère un sous-agent en lecture seule avec sessions_spawn et instruis-le (dans la tâche de spawn) pour exécuter le skill de relecteur correspondant contre l'entité (passe ideaUuid pour la relecture de code), puis interroge son VERDICT. Si la génération est désactivée par la politique, exécute la procédure du relecteur toi-même en tant que passe de lecture seule ciblée et enregistre le VERDICT via chorus_add_comment. Chacun poste exactement un commentaire VERDICT: PASS / PASS WITH NOTES / FAIL. Les verdicts sont consultatifs — ils ne valident pas automatiquement, ne vérifient pas automatiquement, ne bloquent pas en dur ; tu lis les BLOCKERs et tu décides. Un FAIL signifie router les BLOCKERs en retour pour une correction avant de progresser (pour une relecture de code FAIL, ajoute des tâches de correction à la proposition approuvée via /quick-dev et réexécute une fois qu'elles sont done). Voir /review pour le modèle complet.

Choisir un mode de collaboration

Choisis le mode le plus léger qui correspond à la forme du travail :

Conseils : démarre étroit. Si un propriétaire unique peut tenir toute la fonctionnalité dans sa tête, préfère propriétaire unique — le surcoût de coordination n'est pas gratuit. Atteins le déploiement seulement quand les tranches sont véritablement indépendantes (portée séparée, élaboration séparable). Utilise les vagues de tâches parallèles seulement après qu'une proposition soit approuvée et son DAG réel ; respecte les dépendances — to_verify ne débloque pas en aval, seul done le fait.

Propriétaire unique & discipline de concurrence

• Un assignataire responsable par idée à la fois. Cela reflète la sémantique du propriétaire unique du daemon : l'idée est la racine d'épingle faisant autorité, et les propositions/tâches/réveils de son propriétaire héritent cette identité. Ne laisse pas une idée ambiguïment « possédée par l'équipe ».
• Ne fais pas de course sur les sessions en double sur le même travail. Deux sessions daemon (ou deux agents) pilotant la même idée/tâche vont entrer en collision sur les transitions d'état et produire des réveils conflictuels. Assigne, puis laisse un propriétaire s'exécuter.
• Épingle avec instanceUuid quand le travail est attaché à un lieu. Si le code d'une idée enfant vit sur un host/cwd spécifique, épingle l'assignation à cette AgentInstance pour que chaque réveil en aval atterrisse là au lieu d'un daemon aléatoire.

Portes de conversation inversée (tu ne déploies jamais en auto)

Chorus est l'IA propose, les humains vérifient. En tant qu'orchestrateur tu appliques cela, tu ne le contournes pas :

• Porte de proposition. Quand un propriétaire délégué soumet une proposition, ARRÊTE. Exécute le relecteur de proposition, puis remets la décision d'approuver/rejeter au propriétaire humain. Ne t'auto-approuve pas juste parce que tu peux (proposal:admin).
• Porte de vérification. Quand une tâche atteint to_verify, ARRÊTE. Exécute le relecteur de tâche, puis laisse l'humain vérifier. La permission de vérifier n'est pas l'autorisation de valider en caoutchouc ton propre travail coordonné.
• Ne fusionne ou ne pousse jamais. L'orchestrateur pilote le travail jusqu'à « PR prête » et la remet à l'humain — il ne fusionne pas, ne pousse pas, ou ne déploie pas d'une autre manière de façon autonome.

@mentionne le propriétaire à chaque porte pour que la passation soit explicite et vérifiable.

Dériver une idée enfant vs ajouter une tâche vs assigner directement

Règle empirique : nouvelle portée → idée enfant ; unité de même proposition → tâche ; seul le propriétaire change → assigne.