Orchestrer avec 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 tout le 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 points de contrôle qualité, et contrôle les portes d'approbation/vérification gérées par les humains — mais ne livre jamais seul.

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

• $yolo — un seul agent pilote tout le pipeline en solo. L'orchestration est l'opposé : plusieurs agents, chacun propriétaire d'une part, 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 cette skill

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

• Tu possèdes un thème / épic / 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 de motivation : 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 débloquées en vagues parallèles.
• Tu as besoin d'une relecture adversariale indépendante de la proposition / tâche / feature de quelqu'un d'autre avant qu'elle avance.
• Tu es le propriétaire responsable et dois maintenir un assigné 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é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'assigné est réveillé et avance depuis l'étape actuelle de l'idée — il ne re-réclame pas. Si l'idée est open elle passe à elaborating ; tout autre statut est préservé. L'assigné 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éconfigurations comme pm_agent/admin_agent, ou une permission explicite) ou l'appel est rejeté. Les cibles utilisateur doivent être dans ton entreprise. instanceUuid est rejeté pour les cibles utilisateur.
• Prise de contrôle silencieuse. Réassigner une idée déjà possédée transfère simplement la propriété au nouvel assigné — il y a un propriétaire à la fois, pas de prompt de confirmation. Utilise cela 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 détenir task:write), instanceUuid optionnel. La tâche doit être open ou assigned. L'assigné est réveillé pour l'exécuter. Utilise cela 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. Lis l'idée conteneur/thème et son contexte (chorus_get_idea, chorus_get_documents, chorus_get_comments).
2. Pour chaque slice 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 avance indépendamment.
4. @mentionne chaque assigné et le propriétaire du thème pour que la délégation soit visible.

Relecture indépendante comme porte adversariale

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

Produis un sous-agent relecteur avec spawn_agent(agent_type="default", items=[{type:"skill", path:"chorus:chorus-task-reviewer"}, {type:"text", text:"Review <entity> <uuid>."}]) (Codex livre seulement les rôles default/explorer/worker). 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, ni ne bloquent fermement ; tu lis les BLOCKERs et tu décides. Un FAIL signifie renvoyer les BLOCKERs pour une correction avant d'avancer (pour un FAIL de code-review, ajoute des tâches de correction à la proposition approuvée via $quick-dev et relance une fois qu'elles sont done). Voir $review pour le motif complet.

Choisir un mode de collaboration

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

Conseil : commence étroit. Si un propriétaire unique peut tenir la feature entière en tête, préfère propriétaire unique — la surcharge de coordination n'est pas gratuite. Accède à distribution seulement quand les slices sont réellement indépendantes (scope séparé, élaboration séparable). Utilise vagues de tâches parallèles seulement après qu'une proposition est approuvée et que son DAG est réel ; respecte les dépendances — to_verify ne débloque pas les suivantes, seulement done le fait.

Propriétaire unique & discipline de concurrence

• Un assigné 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 autoritaire, et les propositions/tâches/réveils du propriétaire en héritent l'identité. Ne laisse pas une idée ambiguement « possédée par l'équipe ».
• Ne crée pas de race sur des sessions dupliquées du 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. Assigne, puis laisse un propriétaire exécuter.
• Épingle avec instanceUuid quand le travail est lié à 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 aval y atterrisse au lieu d'un daemon aléatoire.

Portes de Conversation-Inversée (tu ne livres jamais automatiquement)

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

• Porte d'élaboration (résolution/skip de gateway). Quand une idée enfant que tu as assignée à un autre agent a son élaboration répondue, tu peux fermer la porte d'élaboration toi-même via chorus_pm_validate_elaboration (ou chorus_pm_skip_elaboration pour une idée trivialement claire) même si tu n'es pas l'assigné — détenir idea:admin suffit. C'est la parité MCP du UI Verify-Elaborate : il réveille l'agent assigné pour écrire la proposition. Tu contrôles la porte ; l'assigné authored toujours la proposition (Conversation-Inversée préservée).
• Porte de proposition. Quand un propriétaire délégué soumet une proposition, ARRÊTE. Exécute le relecteur de proposition, puis remet la décision approbation/rejet 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 tamponner sans question ton propre travail coordonné.
• Ne fusionne jamais ou ne pousse jamais. L'orchestrateur pilote le travail jusqu'à « PR ready » et le remet à l'humain — il ne fusionne, ne pousse, ni ne livre de manière autonome.

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

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

Règle générale : nouveau scope → idée enfant ; unité même-proposition → tâche ; seul le propriétaire change → assigne.