Orchestrate Skill

Cette skill est pour un orchestrateur (typiquement un agent preset Admin) qui coordonne d'autres agents et humains sur l'ensemble du cycle de vie AI-DLC au lieu de faire tout le travail lui-même. L'orchestrateur décompose le travail, confie chaque pièce à un propriétaire choisi, lance des relecteurs indépendants comme portes de qualité, et contrôle les portes d'approbation/vérification gérées par l'humain — mais ne déploie jamais de son propre chef.

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

• yolo-chorus (<BASE_URL>/skill/yolo-chorus/SKILL.md) — un agent pilote tout le pipeline en solo. L'orchestration est l'inverse : plusieurs agents, chacun propriétaire d'une pièce, coordonnés par vous.
• idea-chorus, proposal-chorus, develop-chorus, review-chorus, quick-dev-chorus — une étape unique 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 skill

Utilisez-la quand plus d'un agent (ou agent + humain) va toucher 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 worker 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 proposal 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 de la proposal / tâche / feature de quelqu'un d'autre avant qu'elle avance.
• Vous êtes le propriétaire responsable et devez 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é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 avance à partir de l'étape actuelle de l'idée — il ne réclame PAS. Si l'idée est open elle passe à elaborating ; tout autre statut est préservé. L'assignataire continue d'où l'idée est déjà (élaboration, ready-for-proposal, etc.).
• Les cibles agents doivent détenir idea:write (via un preset tel que pm_agent/admin_agent, ou une permission explicite) ou l'appel est rejeté. Les cibles utilisateurs doivent être dans votre entreprise. instanceUuid est rejeté pour les cibles utilisateurs.
• Prise en charge 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, aucune invite 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 proposal 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. 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 avance indépendamment.
4. @mentionnez chaque assignataire et le propriétaire du thème afin que la délégation soit visible.

Relecture indépendante comme porte adversaire

Chorus utilise trois relecteurs adversaires en lecture seule comme portes de qualité. En tant qu'orchestrateur vous les exécutez aux trois portes et agissez sur le verdict — c'est votre principal levier de qualité quand vous n'écrivez pas le code vous-même.

Créez un sous-agent en lecture seule qui charge la skill relecteur correspondante et l'UUID cible (passez ideaUuid pour la relecture de code) ; si votre harnais n'a pas de primitive de sous-agent, exécutez vous-même la procédure du relecteur en ligne. Chacun poste exactement un commentaire VERDICT: PASS / PASS WITH NOTES / FAIL. Les verdicts sont consultatifs — ils n'auto-approuvent pas, n'auto-vérifient pas, ne bloquent pas dur ; vous lisez les BLOCKERs et décidez. Un FAIL signifie renvoyer les BLOCKERs pour correction avant d'avancer (pour un FAIL de relecture de code, ajoutez des tâches de fix à la proposal approuvée via quick-dev-chorus et relancez une fois qu'elles sont done). La section Independent Review de la skill core chorus (<BASE_URL>/skill/chorus/SKILL.md) est la description canonique de ce pattern.

Choisir un mode de collaboration

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

Conseil : commencez étroitement. Si un propriétaire unique peut tenir toute la feature dans sa tête, préférez propriétaire unique — la surcharge de coordination n'est pas gratuite. Passez à déploiement seulement quand les tranches sont véritablement indépendantes (scope distinct, élaboration séparable). Utilisez vagues de tâches parallèles seulement après qu'une proposal est approuvée et son DAG est réel ; respectez les dépendances — to_verify ne débloque pas les étapes aval, 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 pivot faisant autorité, et les proposals/tâches/wakes de son propriétaire héritent de cette identité. Ne laissez pas une idée ambiguïment « possédée par l'équipe ».
• Ne faites pas de courses sur des sessions dupliquées sur le même travail. Deux sessions daemon (ou deux agents) pilotant la même idée/tâche collisionneront sur les transitions de statut et produiront des wakes conflictuels. Assignez, puis laissez un propriétaire unique 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'assignation à cette AgentInstance afin que chaque wake aval atterrisse là au lieu d'un daemon aléatoire.

Portes Conversation-Inversée (vous ne déployez jamais en auto)

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

• Porte d'élaboration (résolution/saut de gateway). 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 est suffisant. Ceci est la parité MCP de l'UI Verify-Elaborate : cela réveille l'agent assignataire pour écrire la proposal. Vous contrôlez la porte ; l'assignataire rédigit toujours la proposal (Conversation-Inversée préservée).
• Porte de proposal. Quand un propriétaire délégué soumet une proposal, STOP. Exécutez le relecteur de proposal, puis confiez 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, STOP. Exécutez le relecteur de tâche, puis laissez l'humain vérifier. La permission de vérifier n'est pas l'autorisation de tamponner votre propre travail coordonné.
• Ne fusionnez jamais ou ne poussez jamais. L'orchestrateur pilote le travail jusqu'à « PR ready » et le remet à l'humain — il ne fusionne pas, ne pousse pas, ou ne déploie pas de manière autonome autrement.

@mentionnez le propriétaire à chaque porte afin que la transmission soit explicite et vérifiable.

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

Règle d'or : scope nouveau → idée enfant ; unité même-proposal → tâche ; seul le propriétaire change → assign.