Skill Orchestration

Ce skill est destiné à un orchestrateur (généralement un agent préréglé 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, exécute des relecteurs indépendants comme points de contrôle qualité, et gère les portes d'approbation/vérification détenues par les humains — mais ne déploie jamais seul.

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

• skill_view("chorus:yolo") — un agent pilote tout le pipeline seul. L'orchestration est l'inverse : plusieurs agents, chacun possédant une part, coordonnés par vous.
• skill_view("chorus:idea"), skill_view("chorus:proposal"), skill_view("chorus:develop"), skill_view("chorus:review"), skill_view("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 ce skill

Utilisez-le 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 dev Claude, 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 adversariale indépendante d'une proposition / tâche / fonctionnalité de quelqu'un d'autre avant qu'elle ne progresse.
• Vous êtes le propriétaire responsable et devez conserver un assignataire comptable par idée tandis que le travail se déploie.

Préalable : 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 du stade actuel 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'assignataire reprend où l'idée en est déjà (élaboration, ready-for-proposal, etc.).
• Les cibles d'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.
• Prise de possession silencieuse. Réassigner une idée déjà possédée transfère simplement la propriété au nouvel assignataire — il y a un propriétaire à la fois, pas de prompt de confirmation. Utilisez cela délibérément, 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, d'un bout à l'autre :

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 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

Le plugin Chorus Hermes expédie trois skills relecteur en lecture seule (chorus:chorus-proposal-reviewer, chorus:chorus-task-reviewer, chorus:chorus-code-reviewer). En tant qu'orchestrateur vous les exécutez comme enfants delegate_task aux trois portes et agissez selon le verdict — c'est votre levier qualité principal quand vous n'écrivez pas le code vous-même.

Exécutez un relecteur avec delegate_task, en commençant context par le marqueur [chorus-reviewer:proposal|task|code] (mettez-le aussi dans goal) pour que le plugin exécute l'enfant en lecture seule :

delegate_task(
  goal="[chorus-reviewer:task] Review Chorus task <task-uuid> and post one VERDICT comment.",
  context="[chorus-reviewer:task]\nFirst call skill_view(\"chorus:chorus-task-reviewer\") and follow it.\nTask UUID: <task-uuid>\nMax review rounds: 3\nRepo: <abs repo path>\nEvidence: <abs paths of the evidence bundle files>",
)

L'enfant a un contexte isolé et ne peut pas exécuter terminal, donc passez chaque UUID dans context, et pour les révisions de tâche et code construisez d'abord le paquet de preuves vous-même (diff, journal de commits, et sortie de test/build écrite dans les fichiers sous /tmp/chorus-review/<uuid>/). Les exemples complets de proposition / tâche / code sont dans le skill de relecture (skill_view("chorus:review"), Review Strategy). delegate_task se bloque jusqu'à ce que le relecteur finisse ; il n'y a pas de handle à fermer, et un relecteur n'obtient pas de session Chorus. Puis lisez son commentaire VERDICT avec chorus_get_comments. Chacun affiche exactement un commentaire VERDICT: PASS / PASS WITH NOTES / FAIL. Les verdicts sont consultatifs — ils n'approuvent pas automatiquement, ne vérifient pas automatiquement, ne bloquent pas définitivement ; vous lisez les BLOCKERs et décidez. Un FAIL signifie acheminer les BLOCKERs en retour pour une correction avant d'avancer (pour un code-review FAIL, ajoutez des tâches de correction à la proposition approuvée via skill_view("chorus:quick-dev") et relancez une fois qu'elles sont done). Consultez skill_view("chorus:review") pour le motif complet, y compris le plafond de ronde et la gestion sans-VERDICT.

Choisir un mode de collaboration

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

Orientation : commencez étroit. Si un propriétaire unique peut tenir la feature entière en tête, préférez single-owner — la surcharge de coordination n'est pas gratuite. Optez pour fan-out seulement quand les tranches sont vraiment indépendantes (portée séparée, élaboration séparable). Utilisez parallel task waves seulement après l'approbation d'une proposition et quand son DAG est réel ; respectez les dépendances — to_verify ne débloque pas les étapes en aval, seul done le fait.

Assigner à d'autres agents (chorus_pm_assign_idea / chorus_pm_assign_task) les réveille via leur propre runtime ; sur Hermes la plateforme gateway chorus réveille un agent Hermes assigné. Si vous exécutez plutôt une vague vous-même avec des workers en processus, exécutez-les en tant que batch Hermes delegate_task(tasks=[...]) avec une session Chorus par worker, comme décrit dans skill_view("chorus:develop") (Parallel Workers). Cela ne change que la façon dont les workers sont lancés ; les règles de délégation, relecture et porte ici restent les mêmes.

Single-owner & discipline de concurrence

• Un assignataire comptable responsable par idée à la fois. Ceci reflète la sémantique single-owner du daemon : l'idée est la racine d'épingle autoritaire, et ses propositions/tâches/réveils du propriétaire héritent cette identité. Ne laissez pas une idée ambiguëment « possédée par l'équipe ».
• Ne lancez pas de sessions dupliquées simultanément sur le même travail. Deux sessions daemon (ou deux agents) pilotant la même idée/tâche s'affronteront sur les transitions de statut et produiront des réveils 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 réveil en aval arrive là au lieu d'un daemon aléatoire.

Répondre à l'agent qui vous a réveillé (consultatif)

Quand un agent réveille un pair sur une idée ou tâche partagée — un orchestrateur distribuant un worker, ou tout agent @mentionnant un autre — le réveil surface l'ancre de session live du réveilleur : une note nommant l'agent réveilleur et disant au pair réveillé que le réveilleur a une conversation ouverte sur cette idée. Si vous êtes le pair réveillé, répondez sur la même ressource idée/tâche (commentez-y plutôt que d'ouvrir une nouvelle session) et votre réponse atterrit dans la session live existante du réveilleur, gardant la collaboration sur un fil au lieu de se disperser en une nouvelle.

C'est consultatif, non un routage. Il n'y a pas d'abonnement serveur automatique et rien n'est forcément livré — répondre sur la ressource partagée est simplement où une réponse arrive (via le chemin retour existant), pas un canal garanti. Quand l'origine du réveilleur est hors ligne au moment du réveil, aucune ancre live n'est surfacée et l'échange dégénère en notify-only : la réponse atteint le réveilleur comme une notification ordinaire qu'il récupère à son prochain tour. Seuls les réveils ancrés à l'idée/thème portent cette ancre ; les réveils ad-hoc sans idée partagée ne le font pas.

Portes Reversed-Conversation (vous ne déployez jamais automatiquement)

Chorus est l'IA propose, les humains vérifient. En tant qu'orchestrateur vous l'imposez, 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, après accord humain) même si vous n'êtes pas l'assignataire — détenir idea:admin suffit. C'est la parité MCP de la UI Verify-Elaborate : cela réveille l'agent assignataire pour écrire la proposition. Vous gardez la porte ; l'assignataire écrit toujours la proposition (Reversed-Conversation préservée).
• Porte de proposition. Quand un propriétaire délégué soumet une proposition, ARRÊTEZ. Exécutez 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. Exécutez le relecteur de tâche, puis laissez l'humain vérifier. La permission de vérifier n'est pas l'autorisation de caoutchouc-tamponner votre propre travail coordonné.
• Ne fusionnez ou poussez jamais. L'orchestrateur pilote le travail jusqu'à « PR ready » et le remet à l'humain — il ne fusionne, pousse, ou déploie pas de façon autonome.

@mentionnez le propriétaire à chaque porte pour que la passation soit explicite et auditée.

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.