Compétence Chorus Orchestrate

Cette compétence est destinée à un orchestrateur (généralement un agent Admin-preset) 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, exécute des relecteurs indépendants comme des portes de qualité, et contrôle les portes d'approbation/vérification gérées par l'humain — mais ne livre jamais seul.

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

• /chorus-yolo — un seul agent pilote tout le pipeline seul. L'orchestration est l'opposé : plusieurs agents, chacun propriétaire d'une partie, coordonnés par vous.
• /chorus-idea, /chorus-proposal, /chorus-develop, /chorus-review, /chorus-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 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 vous voulez plusieurs agents développeurs travaillant les tâches débloquées en vagues parallèles.
• Vous avez besoin d'une relecture adversaire indépendante d'une proposition / tâche / fonctionnalité d'une autre personne avant qu'elle progresse.
• Vous êtes le propriétaire responsable et devez maintenir un assignataire responsable par idée tandis que le travail s'étend.

Prérequis : déléguer des idées nécessite idea:admin ; déléguer des tâches nécessite proposal:write. Exécutez d'abord chorus_checkin() 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 re-revendique 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 tel que pm_agent/admin_agent, ou une permission explicite) sinon l'appel est rejeté. Les cibles utilisateur doivent être dans votre entreprise. instanceUuid est rejeté pour les cibles utilisateur.
• Reprise silencieuse. Réassigner une idée déjà possédée déplace simplement la propriété au nouvel assignataire — il y a un seul propriétaire à la fois, aucun prompt de confirmation. Utilisez cela délibérément, pas par accident.

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

Confiez une tâche unique à 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

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 — p. 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.

Relecture indépendante comme porte adversaire

Le plugin 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 principal levier de qualité quand vous n'écrivez pas vous-même le code.

Kiro sélectionne automatiquement un relecteur par sa description, et chacun est aussi accessible en tant que commande slash /name. Chacun poste exactement un commentaire VERDICT: PASS / PASS WITH NOTES / FAIL. Les verdicts sont consultatifs — ils n'approuvent pas automatiquement, ne vérifient pas automatiquement, et ne bloquent pas fermement ; vous lisez les BLOCKERs et décidez. Un FAIL signifie renvoyer les BLOCKERs pour correction avant de progresser (pour un FAIL de relecture de code, ajoutez des tâches de correction à la proposition approuvée via /chorus-quick-dev et relancez une fois qu'elles sont done). Voir /chorus-review pour le motif complet.

Choisir un mode de collaboration

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

Orientation : démarrez étroit. Si un propriétaire unique peut tenir toute la fonctionnalité en tête, préférez propriétaire unique — les frais généraux de coordination ne sont pas gratuits. Optez pour distribution uniquement quand les tranches sont véritablement indépendantes (périmètre distinct, élaboration séparable). Utilisez vagues de tâches parallèles seulement après qu'une proposition soit approuvée et son DAG réel ; respectez les dépendances — to_verify ne débloque PAS les tâches suivantes, seul done le fait.

Propriétaire unique et discipline de concurrence

• Un 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 de pin faisant autorité, et les propositions/tâches/réveils de son propriétaire héritent cette identité. Ne laissez pas une idée ambiguë "possédée par l'équipe."
• Ne lancez pas de sessions dupliquées en parallèle 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 réveils conflictuels. Assignez, puis laissez un propriétaire s'exécuter.
• Épinglez avec instanceUuid quand le travail est lié à un endroit. Si le code d'une idée enfant vit sur un host/cwd spécifique, épinglez l'assignment à cette AgentInstance pour que chaque réveil aval atterrisse là plutôt qu'aléatoirement.

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

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

• Porte d'élaboration (gateway resolve/skip). Quand une idée enfant que vous avez assignée à un autre agent a son élaboration répondue, vous pouvez fermer la porte d'élaboration vous-même via chorus_pm_validate_elaboration (ou chorus_pm_skip_elaboration pour une idée trivialement claire) même si vous n'êtes pas l'assignataire — détenir idea:admin suffit. C'est la parité MCP du Verify-Elaborate UI : cela réveille l'agent assignataire pour écrire la proposition. Vous contrôlez la porte ; l'assignataire écrit toujours la proposition (Conversation-Inversée préservée).
• 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 approuver/rejeter au propriétaire humain. Ne vous auto-approuvez pas juste parce que vous 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 l'autorisation de caoutchouter votre propre travail coordonné.
• Ne fusionnez ou poussez jamais. L'orchestrateur pilote le travail jusqu'à "PR ready" et le rend à l'humain — il ne fusionne pas, ne pousse pas, ou ne livre pas autonomement autrement.

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

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

Règle pratique : nouveau périmètre → idée enfant ; unité de même proposition → tâche ; seul le propriétaire change → assign.