Orchestrer une Skill

Cette skill est destinée à un orchestrateur (généralement un agent préconfiguré Admin) qui coordonne d'autres agents et humains sur le cycle de vie de l'AI-DLC plutôt que de faire tout le travail lui-même. L'orchestrateur décompose le travail, confie chaque morceau à un propriétaire choisi, exécute 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 livre jamais de son propre chef.

Namespace d'outil sous dsh. Les noms d'outils bruts ci-dessous (p. ex. chorus_pm_assign_idea) sont la forme lisible ; le nom réellement appelable est préfixé par mcp__chorus__ (mcp__chorus__chorus_pm_assign_idea). Voir la note sur le namespace dans la skill chorus centrale.

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

• yolo-chorus — un seul agent pilote tout le pipeline en solo. L'orchestration est l'inverse : plusieurs agents, chacun possédant une partie, coordonnés par vous.
• idea-chorus, proposal-chorus, develop-chorus, review-chorus, quick-dev-chorus — une seule étape que vous exécutez vous-même. L'orchestration est la couche au-dessus : 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 travailleur spécifique (cas motivant : un propriétaire de thème donne un enfant à Codex, un autre à un agent dev Claude, un autre à un humain).
• Une proposition approuvée a un DAG de tâches et vous voulez plusieurs agents développeurs travaillant sur les tâches débloquées en vagues parallèles.
• Vous avez besoin d'une relecture adversariale indépendante de la proposition / tâche / fonctionnalité de quelqu'un d'autre avant qu'elle n'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 conservé. 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 une préconfig comme 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.
• 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 seul propriétaire à la fois, aucune invite de confirmation. Utilisez cela volontairement, 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 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 — p. ex. un enfant à Codex, un à un agent dev Claude, 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 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, vous les exécutez aux trois portes et agissez en fonction du verdict — c'est votre levier de qualité principal quand vous n'écrivez pas le code vous-même.

Lancez le relecteur avec run_in_background: false (premier plan — l'appel attend et retourne le VERDICT en ligne ; la décision de la porte en dépend) : un subagent en lecture seule dont la tâche doit l'appeler pour utiliser l'outil skill avec le nom exact du relecteur et relire l'entité (passez l'ideaUuid pour la relecture de code) ; puis lisez le plus récent commentaire Chorus VERDICT:. Réglez run_in_background: true (un sous-agent continuable/arrière-plan dont vous récupérez l'avis de règlement plus tard) seulement quand vous voulez délibérément vous déployer. Si le lancement est désactivé par la politique, chargez la skill relecteur et exécutez sa procédure vous-même comme une relecture focalisée en lecture seule. Chaque relecture poste exactement un commentaire VERDICT: PASS / PASS WITH NOTES / FAIL.

Choisir un mode de collaboration

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

Conseil : commencez étroit. Si un propriétaire unique peut garder la fonctionnalité entière en tête, préférez propriétaire unique — la surcharge de coordination n'est pas gratuite. Réservez le déploiement que pour quand les tranches sont vraiment indépendantes (portée séparée, élaboration séparable). Utilisez vagues de tâches parallèles seulement après qu'une proposition est approuvée et son DAG est réel ; respectez les dépendances — to_verify ne débloque pas les étapes suivantes, seul done les débloque.

Propriétaire unique et discipline de concurrence

• Un assignataire responsable par idée à la fois. Ceci reflète la sémantique de propriétaire unique du daemon : l'idée est la racine d'épinglement autoritaire, et la propriété des propositions/tâches/réveils de son propriétaire hérite cette identité. Ne laissez pas une idée ambiguëment « possédée par l'équipe ».
• Ne faites pas de course sur les sessions dupliquées sur le même travail. Deux sessions daemon (ou deux agents) pilotant la même idée/tâche vont collisionner sur les transitions de statut et produire des réveils conflictuels. Assignez, puis laissez un propriétaire 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 pour que chaque réveil en aval atterrisse là plutôt que sur un daemon aléatoire.

Portes de Conversation Inversée (vous ne livrez 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. Exécutez le relecteur de proposition, puis confiez la décision d'approbation/rejet 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. Exécutez le relecteur de tâche, puis laissez l'humain vérifier. La permission de vérifier n'est pas une autorisation de caoutchouc-tamponner votre propre travail coordonné.
• Ne fusionnez ou poussez jamais. L'orchestrateur pilote le travail jusqu'à « PR prêt » et le remet à l'humain — il ne fusionne, ne pousse, ni ne livre autrement de manière autonome.

@mentionnez le propriétaire à chaque porte pour que la transmission 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 → assigner.