Développer une Skill

Cette skill couvre l'étape de Développement du workflow AI-DLC : réclamer des Tasks, écrire du code, signaler la progression, soumettre pour vérification et gérer les sessions pour l'observabilité des sous-agents.

Espace de noms des outils : Les outils Chorus sont exposés par le serveur MCP connecté avec un préfixe mcp__chorus__ sur dsh (par ex. mcp__chorus__chorus_claim_task). Les noms nus sont utilisés ci-dessous pour la lisibilité — préfixez avec mcp__chorus__ lors de l'invocation. Voir chorus pour la règle complète.

Vue d'ensemble

Les Developer Agents prennent en charge les Tasks créées par les PM Agents (via proposal-chorus) et les transforment en code fonctionnel. Chaque tâche suit :

claim --> in_progress --> report work --> self-check AC --> submit for verify --> reviewer --> Admin /review

Pour l'exécution multi-tâches, dsh exécute des vagues séquentielles (l'agent principal traite les tâches dans l'ordre des dépendances) — voir Exécution par vagues ci-dessous.

Outils

Cycle de vie des tâches :

Signalisation du travail :

Critères d'acceptation :

Session (sous-agents uniquement — l'agent principal ignore ceux-ci) :

Sous-agents : toujours passer sessionUuid à chorus_update_task et chorus_report_work pour l'attribution. Agent principal / Team Lead : appelez ces outils sans sessionUuid — aucune session requise.

Outils partagés (checkin, query, comment, search, notifications) : voir chorus

Workflow

Étape 1 : S'enregistrer

chorus_checkin()

Examinez votre personne, vos affectations actuelles et les comptages de travail en attente.

Étape 1.5 : Gérer votre session (sous-agents uniquement)

Ignorez si vous êtes l'agent principal.

Différence dsh : le plugin Claude Code crée automatiquement et injecte la session d'un sous-agent via un hook SubagentStart. dsh n'exécute pas ce hook. La gestion de session est manuelle : si vous êtes un sous-agent et que l'hôte ne vous a pas transmis un sessionUuid, créez-en un vous-même une fois au démarrage, conservez-le pour toutes les opérations de tâche ci-dessous, et fermez-le quand vous avez terminé.

# Créez votre propre session (seulement si aucun sessionUuid ne vous a été fourni)
chorus_create_session({ name: "<descriptive-worker-name>" })
# -> conservez le sessionUuid retourné pour chaque appel de tâche ci-dessous

Si l'hôte dsh a bien injecté un sessionUuid dans votre prompt (certains hôtes transmettent le contexte parent), réutilisez-le au lieu d'en créer un nouveau. En cas de doute, créez-en un — les sessions inactives en double sont inoffensives et deviennent inactives automatiquement après 1 h.

Étape 2 : Trouver du travail

chorus_get_available_tasks({ projectUuid: "<project-uuid>" })

Ou vérifiez vos affectations existantes :

chorus_get_my_assignments()

Étape 3 : Réclamer une tâche

chorus_get_task({ taskUuid: "<task-uuid>" })  # Examinez d'abord
chorus_claim_task({ taskUuid: "<task-uuid>" })

Vérifiez : description, critères d'acceptation, priorité, story points, proposition/documents associés.

Étape 4 : Rassembler le contexte

Chaque tâche et proposition inclut un champ commentCount — utilisez-le pour décider quelles entités ont des discussions dignes d'intérêt.

1. Lisez la tâche et identifiez les dépendances :

   chorus_get_task({ taskUuid: "<task-uuid>" })

   Faites attention à dependsOn (tâches en amont) et commentCount.

2. Lisez les commentaires de la tâche (contient les signalements de travail précédents, la progression, les retours) :

   chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })

3. Examinez les tâches de dépendance en amont — votre travail s'appuie probablement sur le leur :

   chorus_get_task({ taskUuid: "<dependency-task-uuid>" })
   chorus_get_comments({ targetType: "task", targetUuid: "<dependency-task-uuid>" })

   Recherchez : fichiers créés, contrats API, interfaces, compromis.

4. Lisez la proposition d'origine pour comprendre l'intention de conception :

   chorus_get_proposal({ proposalUuid: "<proposal-uuid>", section: "documents" })

   (chorus_get_proposal par défaut section: "basic" — juste les métadonnées + un index de brouillon. Passez section: "documents" pour les docs de conception, ou section: "full" pour les docs + brouillons de tâches.)

5. Lisez les documents du projet (PRD, design technique, ADR) :

   chorus_get_documents({ projectUuid: "<project-uuid>" })

Flux de mise à jour de document (mode OpenSpec) : si la description de la proposition d'origine contient une ligne OpenSpec change slug: <slug>, les Documents PRD / tech_design / spec du projet sont des miroirs de fichiers sous openspec/changes/<slug>/. Pour mettre à jour un tel Document (par ex. clarifier une CA, corriger un scénario de spec avant de renvoyer), chargez la skill openspec-aware-chorus et suivez §3.8 : modifiez d'abord le fichier .md local, puis miroitez via le wrapper CHORUS_MCP_CALL du package local avec json_encode_file et chorus_check_response. (dsh n'a pas de hook SessionStart ; le bundle chorus-dsh préinitialise CHORUS_OPENSPEC_ACTIVE au chargement et la skill la lit, recalculant les trois vérifications en ligne uniquement comme solution de repli — voir openspec-aware-chorus §1.)

⛔ Ne pas appeler chorus_pm_update_document directement depuis le harnais MCP avec un champ content saisi manuellement en mode OpenSpec. Le fichier local est la source de vérité ; le contenu saisi par l'agent dévie et consomme des tokens (openspec-aware-chorus §2 Règle 1).

Quand la DERNIÈRE tâche d'une idée OpenSpec est vérifiée, exécutez vous-même le flux d'archivage (openspec-aware-chorus §3.9) : exécutez openspec archive <slug> --yes, puis miroitez chaque openspec/specs/<capability>/spec.md émis en retour via §3.8. dsh n'a pas de hook PostToolUse pour vous le rappeler — vérifiez après chaque vérification si la tâche qui vient d'être vérifiée était la dernière de son idée, et si oui déclenchez le flux d'archivage vous-même.

Dans le mode sans OpenSpec (pas de ligne de slug, ou pas de CLI openspec), modifiez directement le contenu du Document via l'outil MCP existant sans wrapper, sans étape de fichier local.

Étape 5 : Commencer à travailler

Sous-agent : enregistrez-vous d'abord à la tâche :

chorus_session_checkin_task({ sessionUuid: "<session-uuid>", taskUuid: "<task-uuid>" })

Ensuite, marquez comme en cours :

# Sous-agent :
chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress", sessionUuid: "<session-uuid>" })

# Agent principal :
chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })

Respect des dépendances : Si cette tâche a des dépendances non résolues (tâches dependsOn non en done ou closed), l'appel sera rejeté avec des informations de blocage détaillées. Utilisez chorus_get_unblocked_tasks pour trouver les tâches que vous pouvez démarrer maintenant.

Étape 6 : Signaler la progression

Signalez régulièrement avec chorus_report_work. Incluez :

• Ce qui a été complété
• Fichiers créés ou modifiés
• Commits et PR Git
• Statut actuel / travail restant
• Bloqueurs ou questions

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Progression :\n- Créé src/services/auth.service.ts\n- Commit : abc1234\n- Restant : tests unitaires",
  sessionUuid: "<session-uuid>"
})

Signalez avec mise à jour du statut une fois terminé :

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Implémentation complètement terminée :\n- Fichiers : ...\n- PR : https://github.com/org/repo/pull/42\n- Tous les tests réussissent",
  status: "to_verify",
  sessionUuid: "<session-uuid>"
})

Étape 7 : Auto-vérifier les critères d'acceptation

Avant de soumettre, vérifiez les critères d'acceptation structurés :

task = chorus_get_task({ taskUuid: "<task-uuid>" })

# Si task.acceptanceCriteriaItems est non vide :
chorus_report_criteria_self_check({
  taskUuid: "<task-uuid>",
  criteria: [
    { uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Les tests unitaires couvrent ceci" },
    { uuid: "<criterion-uuid>", devStatus: "passed", devEvidence: "Vérifié manuellement" }
  ]
})

Pour les critères requis, continuez à travailler jusqu'à pouvoir auto-vérifier comme passed. Utilisez failed seulement pour les critères optionnels hors périmètre.

Étape 8 : Soumettre pour vérification

Sous-agents — désenregistrez-vous d'abord :

chorus_session_checkout_task({ sessionUuid: "<session-uuid>", taskUuid: "<task-uuid>" })

Puis soumettez :

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Implémentation de la fonctionnalité d'authentification :\n- Endpoints de connexion/déconnexion ajoutés\n- Middleware JWT\n- Couverture de test de 95 %\n- Tous les CA auto-vérifiés (3/3 réussis)"
})

to_verify ne débloque PAS les tâches en aval — seul done (après vérification admin) le fait.

Étape 8.5 : Exécuter le revue des tâches (en ligne — pas de hook sur dsh)

Différence dsh : le plugin Claude Code repose sur un hook PostToolUse pour injecter un rappel "spawner le revue" après chorus_submit_for_verify. dsh n'a pas d'un tel hook. Exécutez l'étape du revue en ligne, ici même, immédiatement après la soumission. Ne attendez pas un rappel injecté.

Obtenez un VERDICT indépendant avant que la tâche soit vérifiée :

1. Préféré — spawner un sous-agent revue (premier plan). Utilisez l'outil subagent dsh pour spawner un sous-agent avec run_in_background: false (premier plan — l'appel attend et retourne le résultat en ligne ; la décision de vérification/réouverture dépend du verdict) dont la tâche lui dit d'appeler l'outil skill avec task-reviewer-chorus, puis de reviser la tâche. Le résultat faisant autorité est le commentaire VERDICT: le plus récent sur la tâche. Définissez run_in_background: true (un sous-agent de fond/continuable dont vous collectez la notification de conclusion plus tard) seulement si vous voulez délibérément faire fan-out et n'avez pas besoin du verdict avant votre prochaine étape.

   Charger et exécuter la skill task-reviewer-chorus pour vérifier taskUuid <uuid>. Lisez la tâche, ses CA, les documents de la proposition et le code ; exécutez les tests du projet ; vérifiez chaque CA indépendamment ; postez votre commentaire VERDICT sur la tâche quand vous avez terminé.

2. Solution de repli — révisez-la vous-même. Si subagent n'est pas disponible sur votre hôte (spawning désactivé par la politique), effectuez vous-même la revue comme un passage fourni, en lecture seule suivant la procédure de la skill task-reviewer-chorus : lisez chorus_get_task, chorus_get_comments, la proposition d'origine et ses documents ; lisez le code qui implémente chaque CA (ne faites pas confiance au résumé du développeur) ; exécutez les commandes test/build du projet ; vérifiez chaque critère d'acceptation indépendamment. Enregistrez ensuite le résultat vous-même via chorus_add_comment se terminant par une ligne VERDICT: (PASS / PASS WITH NOTES / FAIL). Ne MODIFIEZ PAS les fichiers du projet lors de ce passage — c'est une revue en lecture seule (bash en lecture seule pour tests/build est correct). Utilisez la même classification BLOCKER vs NOTE que la skill task-reviewer-chorus définit.

3. Lisez le VERDICT et agissez :

   chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })

   Trouvez le commentaire le plus récent contenant VERDICT: :

   • VERDICT: PASS — Tous les CA vérifiés, aucun problème. Passez à la vérification admin.
   • VERDICT: PASS WITH NOTES — Tous les CA vérifiés, notes mineures. Passez à la vérification admin (les notes ne bloquent pas).
   • VERDICT: FAIL — BLOCKERs trouvés. Ne vérifiez PAS. Corrigez les BLOCKERs listés dans le commentaire du revue, puis renvoyez (Étape 9).

Si vous avez spawné un sous-agent et aucun nouveau commentaire VERDICT: n'apparaît après son retour, il a épuisé son budget de tours. Respawnez-le UNE FOIS avec un indice de budget concis : "Restez dans le budget de tours. Ignorez la vérification approfondie. Récupérez tâche/proposition/commentaires, exécutez seulement les tests principaux, et postez votre VERDICT dans les 12 premiers tours." Si la deuxième tentative produit toujours aucun VERDICT, revenez à la revue manuelle (solution de repli Étape 8.5) et postez le VERDICT vous-même.

Passerelle de revue de code finale (après la DERNIÈRE tâche de l'idée vérifiée) : quand la tâche que vous venez de vérifier est la dernière tâche de sa proposition enracinée dans une idée, la fonctionnalité est sur le point d'être livrable — exécutez la passerelle de revue de code à l'heure du navire avant de déclarer l'idée complète. En ligne (pas de hook sur dsh), même mécanisme que l'étape 8.5 : spawner un sous-agent via subagent avec run_in_background: false (premier plan — l'appel attend et retourne le verdict en ligne ; la décision d'expédition en dépend ; définissez run_in_background: true seulement pour délibérément faire fan-out) dont la task lui dit d'appeler l'outil skill avec code-reviewer-chorus et de la suivre contre l'idée (passez le ideaUuid + numéro de round) ; la solution de repli est une auto-revue en lecture seule suivant la procédure code-reviewer-chorus. Elle revise le changement de code agrégé de l'idée (intégration inter-tâches, architecture, sécurité, régression, couverture au niveau de la fonctionnalité) et poste un commentaire VERDICT: sur l'idée. PASS / PASS WITH NOTES → navire ; FAIL → corriger via le workflow quick-dev (quick-dev-chorus) : chorus_create_tasks avec proposalUuid défini à la proposition actuelle approuvée pour que les tâches de correction s'y attachent (ne rouvrez pas d'anciennes tâches). Groupez les petits BLOCKERs connexes en une seule tâche cohésive par défaut ; divisez seulement pour les corrections matériellement grandes ou indépendamment testables. Chaque tâche de correction doit auto-vérifier ses critères d'acceptation et passer la revue de tâche indépendante plus la vérification admin. Réexécutez la passerelle seulement après que chaque tâche de correction soit avec succès done ; s'il y a une tâche de correction échouée ou annulée, arrêtez et escaladez à la place. Consultatif/comportemental. Exécutez-le avant tout rapport de fin d'idée.

Étape 9 : Gérer les retours du revue

Si le revue retourne FAIL, ou si la tâche est rouverte après vérification :

Tous les critères d'acceptation sont réinitialisés à en attente quand une tâche est rouverte.

1. Vérifiez les retours :

   chorus_get_task({ taskUuid: "<task-uuid>" })
   chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })

2. Corrigez chaque BLOCKER listé dans le commentaire FAIL du revue.
3. Enregistrez-vous à nouveau (sous-agent), corrigez les problèmes, signalez les corrections, renvoyez, et réexécutez le revue (Étape 8.5).

Étape 10 : Tâche complète

Une fois qu'Admin vérifie (status: done), passez à la prochaine tâche disponible (retour à l'Étape 2).

Étape 11 : Rapport de fin d'idée (consultatif)

Si la tâche que vous venez d'auto-vérifier était la DERNIÈRE de son idée et que vous avez document:write, créez le rapport de fin quand la wake l'exige explicitement. Sinon, laissez-le pour l'orchestrateur ; dans un tour de daemon-headless, ne bloquez pas l'achèvement de la tâche sur un choix de rapport interactif.

Session (sous-agents uniquement)

Différence dsh : le cycle de vie de la session est manuel sur dsh. Le plugin Claude Code automatise la création, le heartbeat et le nettoyage via des hooks ; dsh n'exécute pas ces hooks. Un sous-agent gère donc sa propre session :

1. chorus_create_session({ name }) — une fois au démarrage, sauf si l'hôte vous a déjà donné un sessionUuid
2. chorus_session_checkin_task({ sessionUuid, taskUuid }) — avant de commencer le travail sur chaque tâche
3. Passez sessionUuid à chorus_update_task et chorus_report_work pour l'attribution
4. chorus_session_checkout_task({ sessionUuid, taskUuid }) — quand vous avez terminé chaque tâche
5. chorus_close_session({ sessionUuid }) — quand le sous-agent a terminé (aucun hook ne le ferme pour vous)

Pour garder une session de longue durée visible/active, envoyez chorus_session_heartbeat({ sessionUuid }) régulièrement (n'importe quel outil touchant une session la rafraîchit également).

Agent principal / Team Lead : aucune session requise — appelez les outils sans sessionUuid.

Exécution par vagues sur dsh

Différence dsh : dsh n'a pas de primitive Agent Teams / TeamCreate. Le plugin Claude Code peut spawner une équipe parallèle par vague ; sur dsh vous (l'agent principal) exécutez les tâches séquentiellement dans l'ordre des dépendances. C'est plus lent que les équipes parallèles mais complète le même pipeline.

Boucle de vague séquentielle

boucle :
  # 1. Trouver les tâches prêtes (toutes les dépendances done/closed)
  unblocked = chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })

  si aucune tâche débloquée et toutes les tâches done/closed :
    break  # Tout complété

  si aucune tâche débloquée mais certaines restent (pas done) :
    break avec note d'escalade  # bloqué — probablement une revue échouée bloquant le DAG

  # 2. Travaillez chaque tâche débloquée vous-même, dans l'ordre :
  pour chaque tâche dans unblocked :
    chorus_claim_task({ taskUuid: task.uuid })
    chorus_update_task({ taskUuid: task.uuid, status: "in_progress" })
    # ... lisez le contexte, implémentez, exécutez les tests (Étapes 4-7) ...
    chorus_report_work({ taskUuid: task.uuid, report: "...", status: "to_verify" })
    chorus_report_criteria_self_check({ taskUuid: task.uuid, criteria: [...] })
    chorus_submit_for_verify({ taskUuid: task.uuid, summary: "..." })
    # Étape 8.5 : exécutez le revue des tâches en ligne ; agissez sur son VERDICT
    # Si vous avez task:admin, vérifiez la tâche à "done" (cela débloque les dépendantes)

  # 3. Boucle — chorus_get_unblocked_tasks retourne maintenant la prochaine vague

Critique : to_verify ne résout PAS les dépendances — seulement done ou closed le fait. Une tâche doit être vérifiée à done (par un Admin, ou par vous si vous avez task:admin) avant que ses dépendantes deviennent débloquées. Si vous n'avez pas task:admin, soumettez chaque tâche pour vérification et demandez à l'admin du projet de vérifier entre les vagues, puis réexécutez chorus_get_unblocked_tasks.

Optimisation Claude-Code uniquement (dégénère en séquentiel ici) : sous le plugin Claude Code, chaque vague peut être envoyée en parallèle via TeamCreate + des sous-agents par tâche. dsh n'a pas de telle primitive, donc la boucle ci-dessus s'exécute en série. Ne tentez PAS d'appeler TeamCreate sur dsh — elle n'existe pas.

Optionnel : dispatch de sous-agents

Si votre hôte dsh supporte le spawning de sous-agents travailleurs (pas Agent Teams, juste des sous-agents génériques), vous pouvez en confier un à chaque tâche. Parce qu'il n'y a pas de hook SubagentStart, le prompt du travailleur doit inclure explicitement les instructions de session manuelle :

Votre UUID de tâche Chorus : <task-uuid>
UUID de projet : <project-uuid>

La gestion de session est MANUELLE sur dsh :
1. chorus_create_session({ name: "<worker-name>" }) -> conservez le sessionUuid
2. chorus_session_checkin_task({ sessionUuid, taskUuid })
3. chorus_update_task({ taskUuid, status: "in_progress", sessionUuid })
4. implémentez, puis chorus_report_work({ ..., sessionUuid })
5. chorus_report_criteria_self_check({ taskUuid, criteria: [...] })
6. chorus_session_checkout_task({ sessionUuid, taskUuid })
7. chorus_submit_for_verify({ taskUuid, summary })
8. chorus_close_session({ sessionUuid })

L'agent principal possède toujours la revue + vérification entre les vagues.

Accès MCP pour sous-agents

Si vous spawnez des sous-agents, assurez-vous qu'ils peuvent atteindre le serveur MCP Chorus — la config du plugin (et donc les outils mcp__chorus__*) doit être disponible dans l'environnement du sous-agent, et la clé API doit porter les permissions requises.

Dépannage

Bonnes pratiques de signalisation de travail

Bon rapport (active la continuité de session) :

Implémentation du flux de réinitialisation de mot de passe :

Fichiers créés/modifiés :
- src/services/auth.service.ts (nouveau)
- src/app/api/auth/reset/route.ts (nouveau)
- tests/auth/reset.test.ts (nouveau)

Git :
- Commit : a1b2c3d "feat: password reset flow"
- PR : https://github.com/org/repo/pull/15

Détails d'implémentation :
- POST /api/auth/reset-request : envoie email avec token
- Token expire après 1 heure, usage unique
- Rate limiting : 3 demandes/heure/email
- 12 nouveaux tests, tous réussissent

Critères d'acceptation :
- [x] L'utilisateur peut demander la réinitialisation par email
- [x] Le lien de réinitialisation expire après 1 heure
- [x] Le rate limiting prévient les abus

Mauvais rapport : Terminé.

Conseils

• Lisez les commentaires de tâche en premier — ils contiennent les signalements de travail précédents pour la continuité de session
• Vérifiez les dépendances en amont — lisez les tâches dependsOn et leurs commentaires pour les interfaces/APIs
• Lisez la proposition d'origine — comprenez la logique de conception et le DAG des tâches
• Utilisez commentCount — ignorez la récupération de commentaires sur les entités avec compte 0
• Signalez la progression fréquemment — incluez les chemins de fichiers, commits et PR
• Écrivez des résumés de soumission détaillés — Admin en a besoin pour vérifier
• Exécutez toujours le revue en ligne après la soumission (Étape 8.5) — dsh n'a pas de hook pour vous le rappeler
• Les sessions sont manuelles sur dsh — créez, enregistrez-vous/désenregistrez-vous, et fermez votre propre session en tant que sous-agent
• Si bloqué, ajoutez un commentaire et envisagez de libérer la tâche
• Une tâche à la fois : terminez-la ou libérez-la avant de réclamer une autre

Quand libérer une tâche

Libérez si :

• Vous ne pouvez pas la compléter (connaissance manquante, bloquée)
• Une tâche de priorité plus élevée nécessite de l'attention
• Vous ne terminerez pas dans un délai raisonnable

chorus_release_task({ taskUuid: "<task-uuid>" })
chorus_add_comment({ targetType: "task", targetUuid: "<task-uuid>", content: "Libération : raison..." })

Suivant

• Après la soumission pour vérification, un Admin revise en utilisant review-chorus
• Wake humaine "Yolo" : une wake yolo_requested (l'humain a cliqué Yolo sur le panneau de détail de l'idée) signifie : conduire l'IDÉE ENTIÈRE à done via la skill yolo (le pipeline AI-DLC entièrement automatique), pas juste l'étape d'exécution — lisez l'état actuel de l'idée et reprenez à partir de quelle que soit la phase dans laquelle elle se trouve. Elle est adaptative à l'étape, et elle ne doit jamais fusionner ou pousser une PR sans approbation humaine explicite.
• Pour la vue d'ensemble de la plateforme et les outils partagés, voir chorus