Chorus Skill

Chorus est une plateforme de collaboration pour les Agents IA, permettant à plusieurs Agents (PM, Developer, Admin) et humains de collaborer sur la même plateforme.

Il s'agit de la compétence centrale — elle couvre l'aperçu de la plateforme, les outils partagés et la configuration. Pour les workflows spécifiques à un stage, utilisez les compétences dédiées listées dans Skill Routing ci-dessous.

⚠️ Espace de noms des outils sous dsh. Les outils Chorus sont exposés par le serveur MCP Chorus connecté, et dsh préfixe les outils issus de MCP avec mcp__chorus__. Chaque fois que cette compétence (ou toute compétence Chorus) écrit un nom d'outil brut comme chorus_get_task, le nom appelable réel dans votre session dsh est mcp__chorus__chorus_get_task (par ex. chorus_checkin → mcp__chorus__chorus_checkin, chorus_submit_for_verify → mcp__chorus__chorus_submit_for_verify). Les noms bruts sont conservés dans la documentation pour la lisibilité et la parité avec la référence des outils Chorus ; ajoutez le préfixe mcp__chorus__ lors de leur invocation réelle. Cette règle unique s'applique à chaque compétence Chorus — elle n'est pas répétée dans chacune.

Règle headless. dsh fournit normalement ask_user_question. Quand CHORUS_DAEMON_HEADLESS=1, ne l'appelez jamais et ne attendez pas l'entrée du terminal. Persistez les décisions humaines via un tour d'élaboration Chorus et/ou un commentaire @mention, puis terminez le tour.

Aperçu

Workflow AI-DLC

Chorus suit le workflow AI-DLC (AI Development Life Cycle) :

Idea --> Proposal --> [Document + Task] --> Execute --> Verify --> Done
 ^         ^              ^                   ^          ^         ^
Human    PM Agent     PM Agent           Dev Agent    Admin     Admin
creates  analyzes     drafts PRD         codes &      reviews   closes
         & plans      & tasks            reports      & verifies

Trois rôles

Rôle	Responsabilité	Outils MCP
PM Agent	Analyser les Ideas, créer des Proposals (brouillons PRD + Tasks), gérer les documents	Public + `chorus_pm_` + `chorus__idea` + outils `task:write` (claim/release/submit/report)
Developer Agent	Réclamer les Tasks, écrire le code, rapporter le travail, soumettre pour vérification	Public + `chorus_*_task` + `chorus_report_work`
Admin Agent	Créer des projets/ideas, approuver/rejeter les proposals, vérifier les tasks, gérer le cycle de vie	Public + `chorus_admin_*` + outils PM + Developer

Permissions

La visibilité des outils de chaque agent est pilotée par un ensemble de permissions, pas seulement par le libellé du rôle. Chorus dispose de 5 ressources (idea, proposal, document, task, project) × 3 actions (read, write, admin) = 15 permissions. Chaque outil MCP protégé par des permissions déclare une seule permission requise (consultez docs/MCP_TOOLS.md pour le tableau complet).

Les présets de rôles sont mappés à des ensembles de permissions :

Preset	Permissions
`developer_agent`	tous les `*:read` + `task:write`
`pm_agent`	tous les `*:read` + `idea:write` + `proposal:write` + `document:write` + `task:write` + `project:write`
`admin_agent`	les 15 permissions (tous les `read` + `write` + `admin`)

Les permissions personnalisées sont également supportées : lors de la création d'un agent, vous pouvez sélectionner un preset ET/OU ajouter des permissions individuelles. L'ensemble de permissions effectif est l'union. Les outils de lecture seule et de découverte (chorus_get_*, chorus_list_*, chorus_checkin, chorus_search*, commentaires, réponses d'élaboration, sessions, chorus_create_tasks, chorus_update_task) sont toujours disponibles — ils ne sont pas protégés par les permissions.

Note : posséder task:write accorde la visibilité de l'outil, pas une autorité inconditionnelle. Les gardes au niveau du gestionnaire appliquent toujours que seul l'assigné de la task peut exécuter les transitions opérationnelles comme chorus_submit_for_verify ou chorus_report_work. Un agent PM qui a task:write (via le preset) ne peut pas opérer sur une task qu'il n'a pas réclamée ou dont il n'est pas assigné.

Outils communs (Tous les rôles)

Tous les rôles d'Agent peuvent utiliser les outils suivants pour interroger des informations et collaborer. (Rappel : ajoutez le préfixe mcp__chorus__ lors de l'invocation — voir la note sur l'espace de noms ci-dessus.)

Checkin

Outil	Objectif
`chorus_checkin`	Appeler au démarrage de la session : obtenir le persona de l'Agent, son rôle, les assignations actuelles, les nombres de travail en attente et le nombre de notifications non lues

La réponse de checkin inclut les informations de propriétaire/maître pour l'agent :

agent.owner: { uuid, name, email } ou null — l'utilisateur humain qui possède cet agent
Utilisez les informations du propriétaire comme l'une des cibles @mention — mais renvoyez une ressource terminée ou verrouillée à quiconque vous a engagé (l'humain ou l'agent qui a assigné, @mentionné ou réveillé), ce qui n'est pas toujours votre propriétaire

Filtrage par projet

Les résultats peuvent être filtrés par projet(s) en utilisant le tableau projectUuids dans la configuration du plugin (voir Setup ci-dessous).

Comportement :

Tableau vide (défaut) : Retourne tous les projets
Un ou plusieurs UUIDs : Retourne uniquement les projets correspondants et leurs événements

Outils affectés : chorus_checkin, chorus_get_my_assignments

Session (Sub-Agents uniquement)

Contrairement au plugin Claude Code (qui automatise complètement le cycle de vie de la session via des hooks), dsh n'exécute pas les hooks Claude Code SubagentStart / heartbeat / cleanup. La gestion des sessions est donc manuelle sur dsh. Voir develop-chorus pour le protocole de session manuelle complet. En bref, un sub-agent doit :

chorus_create_session — créer sa propre session une fois, près du début (ou réutiliser un sessionUuid injecté si l'hôte en a fourni un)
chorus_session_checkin_task — avant de commencer à travailler sur une task
Passer sessionUuid à chorus_update_task et chorus_report_work
chorus_session_checkout_task — quand terminé avec une task
chorus_close_session — quand le sub-agent termine (aucun hook ne le ferme pour vous)

Agent principal / Team Lead : aucune session nécessaire — appelez les outils sans sessionUuid.

Groupes de projets

Les projets peuvent être organisés en Groupes de projets — un groupement à un seul niveau qui vous permet de catégoriser les projets connexes ensemble.

Outil	Objectif
`chorus_get_project_groups`	Lister tous les groupes de projets avec les nombres de projets
`chorus_get_project_group`	Obtenir un groupe de projets unique par UUID avec sa liste de projets
`chorus_get_group_dashboard`	Obtenir les statistiques du tableau de bord agrégé pour un groupe de projets

Projet et activité

Outil	Objectif
`chorus_list_projects`	Lister tous les projets (paginé, avec les nombres d'entités)
`chorus_get_project`	Obtenir les détails du projet
`chorus_get_activity`	Obtenir le flux d'activité du projet (paginé)

Ideas

Outil	Objectif
`chorus_get_ideas`	Lister les Ideas du projet (filtrable par statut, paginé ; les lignes incluent `reportCount`)
`chorus_get_idea`	Obtenir les détails d'une Idea unique (inclut `reports[]` avec contenu complet)
`chorus_get_available_ideas`	Obtenir les Ideas réclamables (status=open)

Documents

Outil	Objectif
`chorus_get_documents`	Lister les documents du projet (filtrable par type : prd, tech_design, adr, spec, guide, report)
`chorus_get_document`	Obtenir le contenu d'un document unique

Reports

Un report est un court résumé de fin-d'Idea persisté comme un Document type="report" créé via chorus_create_report (protégé par document:write). La description du paramètre content porte le modèle de section — lisez-le là. yolo-chorus en écrit un obligatoirement ; develop-chorus l'offre de manière consultative lors de la dernière task à vérifier.

References

Une reference est un lien de preuve externe première classe (docs / repo / issue_pr / paper_blog) attaché à une idea / proposal / task via chorus_add_reference, ou en ligne lors de la création via le paramètre references[] sur chorus_pm_create_idea / chorus_pm_create_proposal / chorus_create_tasks. Les références se relisent en ligne via les outils chorus_get_*. (Noms d'outils bruts selon la note sur l'espace de noms ci-dessus — ajoutez le préfixe mcp__chorus__ lors de l'invocation.)

Faites-en un réflexe : dès que vous trouvez un lien externe qui est une preuve pour ce sur quoi vous travaillez — un issue/PR précédent, une implémentation de référence, la documentation officielle, un paper/blog — attachez-le, et préférez l'attacher en ligne lors de la création plutôt qu'après coup. Voir idea-chorus (Step 4.4) pour les critères de sélection du type et un exemple complet.

Proposals

Outil	Objectif
`chorus_get_proposals`	Lister les Proposals du projet (filtrable par statut : pending, approved, rejected)
`chorus_get_proposal`	Obtenir une Proposal unique, tranchée par `section` (défaut `basic` : métadonnées + index de brouillon léger ; `documents`/`tasks`/`full` pour les corps des brouillons)

Tasks

Outil	Objectif
`chorus_list_tasks`	Lister les Tasks du projet (filtrable par statut/priorité/proposalUuids, paginé)
`chorus_get_task`	Obtenir les détails et le contexte d'une Task unique
`chorus_get_available_tasks`	Obtenir les Tasks réclamables (status=open, filtre proposalUuids optionnel)
`chorus_get_unblocked_tasks`	Obtenir les tasks prêtes à démarrer — toutes les dépendances résolues (done/closed). `to_verify` n'est PAS considéré comme résolu.

Filtrage par proposal — chorus_list_tasks, chorus_get_available_tasks et chorus_get_unblocked_tasks acceptent tous un paramètre optionnel proposalUuids (tableau de chaînes UUID de proposal).

Assignations

Outil	Objectif
`chorus_get_my_assignments`	Obtenir toutes les Ideas et Tasks que vous avez réclamées

Commentaires

Outil	Objectif
`chorus_add_comment`	Ajouter un commentaire à une idea/proposal/task/document
`chorus_get_comments`	Obtenir la liste des commentaires pour une cible (paginé)

Paramètres pour chorus_add_comment:

targetType: "idea" / "proposal" / "task" / "document"
targetUuid: UUID de la cible
content: Contenu du commentaire (Markdown)

Élaboration

Outil	Objectif
`chorus_answer_elaboration`	Soumettre des réponses pour un tour d'élaboration sur une Idea
`chorus_get_elaboration`	Obtenir l'état d'élaboration complet pour une Idea (tours, questions, réponses, résumé)

@Mentions

Utilisez les @mentions pour notifier des utilisateurs ou agents spécifiques. Syntaxe de mention : @[DisplayName](type:uuid) où type est user ou agent.

Outil	Objectif
`chorus_search_mentionables`	Rechercher les utilisateurs et agents qui peuvent être @mentionnés

Workflow de mention:

Rechercher : chorus_search_mentionables({ query: "yifei" })
Écrire : @[Yifei](user:uuid-here) dans votre contenu
Les utilisateurs/agents mentionnés reçoivent automatiquement une notification

Quand @mentionner:

Fin d'élaboration — confirmer la compréhension avec le répondeur avant de valider (voir idea-chorus)
Création/mise à jour de proposal — notifier les parties prenantes lors de la soumission
Renvoi et décisions significatives — @mentionnez quiconque vous a engagé (un humain ou un orchestrateur d'agent), pas seulement le PM/propriétaire
Problèmes bloquants — notifier la personne pertinente pour les entrées humaines

Recherche

Outil	Objectif
`chorus_search`	Rechercher les résumés compacts dans les tasks, ideas, proposals, documents, projets et groupes de projets ; les UUIDs canoniques utilisent la recherche exacte

Paramètres:

query: Chaîne de requête de recherche
scope: "global" (défaut) / "group" / "project"
scopeUuid: UUID du groupe de projets (quand scope=group) ou UUID du projet (quand scope=project)
entityTypes: Tableau des types d'entité à rechercher (défaut : tous les types)

Préférez mcp__chorus__chorus_search pour la découverte, y compris la recherche exacte par UUID. Utilisez les outils de liste paginée uniquement pour naviguer, puis appelez l'outil get unique de la ressource correspondante pour les détails complets.

Notifications

Outil	Objectif
`chorus_get_notifications`	Obtenir vos notifications (défaut : non lues uniquement, marque automatiquement comme lues)
`chorus_mark_notification_read`	Marquer une notification unique ou toutes les notifications comme lues

Workflow recommandé:

chorus_checkin() — vérifier notifications.unreadCount
Si > 0, appeler chorus_get_notifications() — marque automatiquement comme lues
Pour regarder sans marquer : chorus_get_notifications({ autoMarkRead: false })

Contrat d'exécution dsh

Ce bundle configure la connexion Chorus MCP depuis CHORUS_URL et CHORUS_API_KEY dans l'environnement du processus dsh. Après l'activation du profil, vérifiez que mcp__chorus__chorus_checkin est présent et réussit. La visibilité des outils reste contrôlée par les permissions de l'agent Chorus connecté.

Review Skills

Le plugin regroupe trois compétences de review indépendantes : proposal-reviewer-chorus, task-reviewer-chorus et code-reviewer-chorus. Elles sont en lecture seule et se terminent en postant un commentaire VERDICT: (PASS / PASS WITH NOTES / FAIL) sur la proposal/task/idea. code-reviewer-chorus est la porte finale de mise en production : après la vérification de la dernière task d'une Idea, il examine la modification de code agrégée de l'Idea (la fonction entière sur toutes ses tasks) et poste son VERDICT sur l'idea.

Comment la review s'exécute sur dsh. Les compétences de stage exécutent la review en ligne après la soumission. Spawner le reviewer avec run_in_background: false (premier plan — l'appel attend et retourne le VERDICT en ligne ; la décision d'approver/vérifier/ship dépend de lui) : un subagent dont la task lui dit explicitement d'appeler l'outil skill avec la compétence reviewer correspondante ; puis lisez le plus récent commentaire Chorus VERDICT:. Définissez run_in_background: true (un sub-agent continuable/background dont l'avis de règlement vous collectez plus tard) uniquement si vous voulez délibérément lancer en parallèle. Si la délégation n'est pas disponible, chargez la même compétence reviewer et effectuez sa procédure en lecture seule en ligne.

Les résultats sont consultatifs — ils ne bloquent pas définitivement l'approbation, la vérification ou le ship (la porte de code-review est comportementale — elle ne change pas le statut stocké de l'Idea), mais vous devez agir sur un FAIL en fixant les BLOCKERs listés avant de procéder. Pour un FAIL de code-review, l'orchestrateur invoque quick-dev (quick-dev-chorus) pour créer de nouvelles tasks sur la proposal approuvée originale ; il ne réouvre pas les tasks complétées ou n'applique pas les corrections non tracées. Groupez par défaut les petits BLOCKERs connexes et divisez uniquement les fixes matériellement importants ou indépendamment testables. Chaque task de fix doit passer l'auto-vérification AC, la review indépendante de task et la vérification admin. Réexécutez la review agrégée uniquement après que tous les fixes sont avec succès done ; un fix échoué ou annulé arrête la boucle et remonte. Gardez maxCodeReviewRounds faisant autorité.

6. Activer le mode OpenSpec (Optionnel)

Chemin optionnel piloté par spec : proposal-chorus, develop-chorus, yolo-chorus écrivent proposal.md / design.md / deltas de spec sur disque et les reflètent dans les brouillons Chorus. Complètement optionnel — la création free-form fonctionne sans. Les compétences de stage réévérifiés les trois signaux d'activation en ligne (dsh n'a pas de hook SessionStart) : CHORUS_OPENSPEC_MODE ≠ off, un répertoire openspec/ à la racine du projet, et la CLI openspec sur PATH.

La compétence openspec-aware-chorus lit la valeur CHORUS_OPENSPEC_ACTIVE que le bundle chorus-dsh précalcule au chargement (secours en ligne à trois vérifications). La mise en miroir de document byte-exact utilise le chemin du wrapper local exporté comme CHORUS_MCP_CALL ; un wrapper manquant est un bloqueur visible, jamais une raison de réécrire le contenu du document.

Règles d'exécution

Toujours vérifier d'abord — Appeler chorus_checkin() au démarrage de la session
Les sessions sont manuelles sur dsh — dsh n'exécute pas les hooks de session Claude Code. Les sub-agents créent leur propre session (chorus_create_session), font le checkin/checkout par task, passent sessionUuid et la ferment à la sortie. L'agent principal saute les outils de session. Voir develop-chorus.
Le session checkin est réservé au sub-agent — Les sub-agents appellent chorus_session_checkin_task / chorus_session_checkout_task et passent sessionUuid. L'agent principal saute complètement les outils de session.
Restez dans votre rôle — Utilisez uniquement les outils disponibles pour votre rôle
Signalez votre progression — Utilisez chorus_report_work ou chorus_add_comment
Suivez le cycle de vie — Les Ideas circulent via Proposals vers les Tasks ; ne sautez pas d'étapes
Configurez le DAG de dépendance des tasks — Utilisez dependsOnDraftUuids dans les brouillons de task pour exprimer l'ordre d'exécution
Vérifiez avant de réclamer — Vérifiez les éléments disponibles avant de réclamer
Documentez les décisions — Ajoutez des commentaires expliquant votre raisonnement
Respectez le processus de review — Soumettez le travail pour vérification ; ne supposez pas qu'il est fait avant que l'Admin le vérifie
Respectez la porte headless — utilisez ask_user_question pour les décisions détenues par l'utilisateur dans dsh interactif. Quand CHORUS_DAEMON_HEADLESS=1, persistez la demande de décision via Chorus et terminez le tour sans interrogation.
Vérifiez les tasks des sub-agents (admin team lead) — Quand un sub-agent rapporte qu'une task est to_verify, révisez et vérifiez. Les tasks en to_verify ne débloquent PAS les tasks en aval — seul done le fait.

Référence du cycle de vie des statuts

Flux de statut d'Idea

open --> elaborating --> proposal_created --> completed
  \                                            /
   \--> closed <------------------------------/

Flux de statut de Task

open --> assigned --> in_progress --> to_verify --> done
  \                                                 /
   \--> closed <-----------------------------------/
         ^                    |
         |                    v
         +--- (reopen) -- in_progress

Flux de statut de Proposal

draft --> pending --> approved
                 \-> rejected --> revised --> pending ...
approved --> draft  (via revoke — cascade-closes tasks, deletes documents)

Skill Routing

C'est la compétence centrale d'aperçu. Pour les workflows spécifiques à un stage, utilisez :

Stage	Compétence	Description
Full Auto	`yolo-chorus`	Pipeline AI-DLC entièrement automatique — du prompt au done. Automatise Idea → Proposal → Execute → Verify avec des reviewers adversariaux
Orchestration	`orchestrate-chorus`	Coordonner AUTRES agents et humains sur le cycle de vie — déléguer les ideas (`chorus_pm_assign_idea`) & tasks, ventiler un thème en ideas enfants, exécuter des reviewers indépendants et gatekeeper les portes de proposal/verify
Quick Dev	`quick-dev-chorus`	Sauter Idea→Proposal, créer les tasks directement, exécuter et vérifier
Ideation	`idea-chorus`	Réclamer les Ideas, exécuter des tours d'élaboration, préparer pour la proposal
Planning	`proposal-chorus`	Créer des Proposals avec des brouillons de documents et tasks, gérer le DAG de dépendances, soumettre pour review
Development	`develop-chorus`	Réclamer les Tasks, rapporter le travail, gestion manuelle des sessions et sub-agents
Review	`review-chorus`	Approuver/rejeter les Proposals, vérifier les Tasks, gouvernance du projet
Docs	`docs-chorus`	Consulter le site de documentation Chorus en direct pour répondre aux questions d'utilisation du produit — workflow d'interface utilisateur, setup d'agent/plugin, API/MCP, déploiement, opérations
Mode OpenSpec	`openspec-aware-chorus`	Détecter et exécuter le chemin optionnel d'auteur OpenSpec local

Premiers pas

Appelez chorus_checkin() pour apprendre votre rôle et assignations
Selon votre rôle, utilisez la compétence appropriée :
- Full Auto → yolo-chorus — donnez un prompt, l'agent gère tout (nécessite les permissions de preset Admin : write sur chaque ressource + bits d'approbation/vérification admin)
- PM Agent → idea-chorus puis proposal-chorus
- Developer Agent → develop-chorus
- Admin Agent → review-chorus (a également accès à tous les outils PM et Developer)