Compétence Orchestration

Cette compétence est destinée à 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 partie à un propriétaire choisi, lance des relecteurs indépendants comme portes de contrôle qualité, et contrôle les portes d'approbation/vérification gérées par l'humain — mais ne déploie jamais seul.

Il complète les autres compétences plutôt que de les remplacer :

• /skill:yolo — un agent pilote tout le pipeline en solo. L'orchestration est l'opposé : plusieurs agents, chacun propriétaire d'une partie, coordonnés par vous.
• /skill:idea, /skill:proposal, /skill:develop, /skill:review, /skill:quick-dev — une seule étape que vous exécutez vous-même. L'orchestration est la couche au-dessus de celles-ci : vous décidez qui exécute chaque étape.

Quand utiliser cette compétence

Utilisez-la quand plus d'un agent (ou agent + humain) touchera au travail et que quelqu'un doit les maintenir cohérents :

• Vous possédez un thème / épique / idée conteneur qui se décompose en plusieurs idées enfants indépendantes, et vous voulez confier chaque enfant à un travailleur spécifique (cas de motivation : un propriétaire de thème confie un enfant à Codex, un autre à un agent Claude dev, un autre à un humain).
• Une proposition approuvée a un DAG de tâches et vous voulez plusieurs agents développeurs travaillant en parallèle sur les tâches débloquées.
• Vous avez besoin d'une revue adversariale indépendante d'une proposition / tâche / fonctionnalité de quelqu'un d'autre avant qu'elle avance.
• Vous êtes le propriétaire responsable et devez maintenir un seul assignataire responsable par idée pendant que le travail se démultiplie.

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

Primitives de délégation

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

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

Comportement que vous devez comprendre :

• L'assignataire est réveillé et progresse à partir de l'étape actuelle de l'idée — il ne se reclaime PAS. Si l'idée est open elle passe à elaborating ; tout autre statut est préservé. L'assignataire reprend là où l'idée est déjà (élaboration, ready-for-proposal, etc.).
• Les cibles agent doivent dé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 votre entreprise. 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 n'y a qu'un propriétaire à la fois, pas d'invite de confirmation. Utilisez ceci intentionnellement, pas par accident.

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

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

Dériver des idées enfants et les distribuer en éventail

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

1. Lisez 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éez une idée enfant avec chorus_pm_create_idea (reliez-la au parent dans le corps / via references[]).
3. Assignez 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. @mentionnez chaque assignataire et le propriétaire du thème pour que la délégation soit visible.

Revue indépendante comme porte adversariale

L'extension livre trois sous-agents relecteurs en lecture seule. En tant qu'orchestrateur vous les lancez aux trois portes et agissez selon le verdict — c'est votre levier de qualité principal quand vous n'écrivez pas le code vous-même.

Lancez un relecteur via subagent_spawn avec la compétence relecteur et l'UUID cible ; après son post, subagent_manage close le pour libérer le slot de concurrence de Pi. 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, ni ne bloquent durément ; vous lisez les BLOCKERs et décidez. Un FAIL signifie router les BLOCKERs pour un correctif avant d'avancer (pour un FAIL de revue de code, ajoutez des tâches de correctif à la proposition approuvée via /skill:quick-dev et relancez une fois qu'elles sont done). Voir /skill:review pour le motif complet.

Choisir un mode de collaboration

Choisissez le mode le plus léger qui convient à la forme du travail :

Guidance : commencez étroit. Si un propriétaire unique peut tenir la fonctionnalité entière dans sa tête, préférez propriétaire unique — la charge de coordination n'est pas gratuite. Recourez à la distribution en éventail uniquement quand les tranches sont vraiment indépendantes (portée séparée, élaboration séparable). Utilisez vagues de tâches parallèles uniquement après qu'une proposition est approuvée et son DAG réel ; respectez les dépendances — to_verify ne débloque pas en aval, seul done le fait.

Propriétaire unique & discipline de concurrence

• Un seul assignataire responsable par idée à la fois. Cela reflète la sémantique de propriétaire unique du daemon : l'idée est la racine pin autoritaire, et les propositions/tâches/appels du propriétaire en héritent l'identité. Ne laissez pas une idée ambiguë « possédée par l'équipe ».
• Ne faites pas de course avec des sessions en doublon sur le même travail. Deux sessions daemon (ou deux agents) pilotant la même idée/tâche entreront en collision sur les transitions de statut et produiront des appels conflictuels. Assignez, puis laissez un propriétaire exécuter.
• Épinglez avec instanceUuid quand le travail est lié à un lieu. Si le code d'une idée enfant vit sur un host/cwd spécifique, épinglez l'assignation à cette AgentInstance pour que chaque appel en aval se pose là au lieu d'un daemon aléatoire.

Portes Conversation-Inversée (vous ne deployez jamais automatiquement)

Chorus est l'IA propose, les humains vérifient. En tant qu'orchestrateur vous l'appliquez, vous ne le contournez pas :

• Porte de proposition. Quand un propriétaire délégué soumet une proposition, ARRÊTEZ. Lancez le relecteur de proposition, puis remettez la décision d'approuver/rejeter au propriétaire humain. Ne vous auto-approuvez pas juste parce que vous le pouvez (proposal:admin).
• Porte de vérification. Quand une tâche atteint to_verify, ARRÊTEZ. Lancez le relecteur de tâche, puis laissez l'humain vérifier. La permission de vérifier n'est pas une autorisation de tamponner aveuglément votre travail coordonné.
• Ne fusionnez ni ne poussez jamais. L'orchestrateur pilote le travail jusqu'à « PR prête » et la remet à l'humain — il ne fusionne, ne pousse, ni ne déploie autonomement.

@mentionnez le propriétaire à chaque porte pour que la transmission soit explicite et auditable.

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

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