Développer une Compétence

Cette compétence couvre l'étape de Développement du workflow AI-DLC : récupérer des tâches, é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 chorus__ sur OpenClaw (par ex. chorus__chorus_claim_task). Les noms nus sont utilisés ci-dessous pour la lisibilité — préfixez avec chorus__ lors de l'invocation. Voir /chorus pour la règle complète.

Vue d'ensemble

Les agents développeurs récupèrent les tâches créées par les agents PM (via /proposal) 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, OpenClaw exécute des vagues séquentielles (l'agent principal traite les tâches dans l'ordre de dépendance) — voir Exécution par vagues ci-dessous.

Outils

Cycle de vie de la tâche :

Signalement de la progression :

Critères d'acceptation :

Session (sous-agents uniquement — l'agent principal saute ces étapes) :

Sous-agents : toujours passer sessionUuid à chorus_update_task et chorus_report_work pour l'attribution. Agent principal / Chef d'équipe : appeler ces outils sans sessionUuid — aucune session nécessaire.

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

Workflow

Étape 1 : S'enregistrer

chorus_checkin()

Examinez votre profil, les assignations actuelles et les compteurs de travail en attente.

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

Passer cette étape si vous êtes l'agent principal.

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

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

Si l'hôte OpenClaw a injecté un sessionUuid dans votre invite (certains hôtes transmettent le contexte parent), réutilisez-le au lieu de 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 1h.

Étape 2 : Trouver du travail

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

Ou vérifier les assignations existantes :

chorus_get_my_assignments()

Étape 3 : Récupérer une tâche

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

Vérifier : la description, les critères d'acceptation, la priorité, les points d'histoire, les propositions/documents associés.

Étape 4 : Rassembler le contexte

Chaque tâche et proposition inclut un champ commentCount — l'utiliser pour décider quelles entités ont des discussions intéressantes.

1. Lire la tâche et identifier les dépendances :

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

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

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

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

3. Examiner 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>" })

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

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

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

   (chorus_get_proposal utilise par défaut section: "basic" — métadonnées et index de brouillon. Passer section: "documents" pour les documents de conception, ou section: "full" pour les documents + brouillons de tâche.)

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

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

Flux de mise à jour des documents (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 des fichiers sous openspec/changes/<slug>/. Pour mettre à jour un tel document (par ex. clarifier un AC, corriger un scénario de spec avant de soumettre à nouveau), charger la compétence openspec-aware et suivre §3.8 : d'abord éditer le fichier .md local, puis le refléter via le wrapper chorus-api.sh avec json_encode_file et chorus_check_response. (OpenClaw exécute la détection d'openspec-aware en ligne — il n'y a pas de hook SessionStart ; voir openspec-aware §1.)

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

Quand la DERNIÈRE tâche d'une idée OpenSpec est vérifiée, exécuter le flux d'archivage vous-même (openspec-aware §3.9) : exécuter openspec archive <slug> --yes, puis refléter chaque openspec/specs/<capability>/spec.md émis via §3.8. OpenClaw n'a pas de hook PostToolUse pour vous le rappeler — vérifier après chaque vérification si la tâche vérifiée était la dernière de son idée, et le cas échéant déclencher le flux d'archivage vous-même.

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

Étape 5 : Commencer à travailler

Sous-agent : s'enregistrer à la tâche d'abord :

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

Puis marquer comme in_progress :

# 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" })

Mise en œuvre de dépendances : si cette tâche a des dépendances non résolues (tâches dependsOn pas en done ou closed), l'appel sera rejeté avec des informations de blocker détaillées. Utiliser chorus_get_unblocked_tasks pour trouver les tâches que vous pouvez commencer maintenant.

Étape 6 : Signaler la progression

Signaler périodiquement avec chorus_report_work. Inclure :

• Ce qui a été complété
• Fichiers créés ou modifiés
• Commits et PRs Git
• Statut actuel / travail restant
• Blockers 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>"
})

Signaler avec mise à jour de statut quand c'est terminé :

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

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

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

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

# Si task.acceptanceCriteriaItems n'est pas 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 obligatoires, continuer à travailler jusqu'à pouvoir auto-vérifier comme passed. N'utiliser failed que pour les critères optionnels qui sont hors de portée.

Étape 8 : Soumettre pour vérification

Sous-agents — se désenregistrer d'abord :

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

Puis soumettre :

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Implémentation de la fonctionnalité d'authentification :\n- Ajouté les endpoints login/logout\n- Middleware JWT\n- Couverture de test 95%\n- Tous les AC 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 vérificateur de tâche (en ligne — pas de hook sur OpenClaw)

Différence OpenClaw : le plugin Claude Code s'appuie sur un hook PostToolUse pour injecter un rappel « déclencher le vérificateur » après chorus_submit_for_verify. OpenClaw n'a pas ce hook. Exécuter l'étape du vérificateur en ligne, ici même, immédiatement après la soumission. Ne pas attendre un rappel injecté.

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

1. Préféré — déclencher un sous-agent vérificateur. Utiliser l'outil OpenClaw sessions_spawn pour déclencher un sous-agent dont la task lui dit d'invoquer la compétence /task-reviewer (incluse dans ce plugin) contre la tâche, puis attendre (sonder l'outil subagents ou utiliser sessions_yield — NE PAS détacher ; vous avez besoin du VERDICT avant de continuer). Le sous-agent hérite des compétences du plugin, donc /task-reviewer lui est disponible ; cette compétence est en lecture seule (bash en lecture seule pour les tests/build autorisé) et poste un commentaire VERDICT: sur la tâche. Exemple d'invite de tâche :

   Exécuter la compétence /task-reviewer pour vérifier taskUuid <uuid>. Lire la tâche, ses AC, les documents de la proposition et le code ; exécuter les tests du projet ; vérifier chaque AC indépendamment ; poster votre commentaire VERDICT sur la tâche quand terminé.

2. Secours — l'examiner vous-même. Si sessions_spawn est indisponible sur votre hôte (la génération de sessions est désactivée par politique), effectuer l'examen vous-même comme une passe focalisée et en lecture seule suivant la procédure de la compétence /task-reviewer : lire chorus_get_task, chorus_get_comments, la proposition d'origine et ses documents ; lire le code qui implémente chaque AC (ne pas faire confiance au résumé du développeur) ; exécuter les commandes de test/build du projet ; vérifier chaque critère d'acceptation indépendamment. Puis enregistrer le résultat via chorus_add_comment se terminant par une ligne VERDICT: (PASS / PASS WITH NOTES / FAIL). NE PAS modifier les fichiers du projet pendant cette passe — c'est une revue en lecture seule (bash en lecture seule pour les tests/build est correct). Utiliser la même classification BLOCKER vs NOTE que la compétence /task-reviewer définit.

3. Lire le VERDICT et agir :

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

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

   • VERDICT: PASS — Tous les AC vérifiés, aucun problème. Procéder à la vérification admin.
   • VERDICT: PASS WITH NOTES — Tous les AC vérifiés, petites remarques. Procéder à la vérification admin (les remarques ne bloquent pas).
   • VERDICT: FAIL — BLOCKERs trouvés. NE PAS vérifier. Corriger les BLOCKERs listés dans le commentaire du vérificateur, puis soumettre à nouveau (Étape 9).

Si vous avez déclenché un sous-agent et aucun nouveau commentaire VERDICT: n'apparaît après son retour, il a épuisé son budget de tours. Le redéclencheur UNE FOIS avec un indice de budget concis : « Rester dans le budget de tours. Sauter la vérification approfondie. Récupérer la tâche/proposition/commentaires, exécuter uniquement les tests essentiels, et poster votre VERDICT dans les 12 premiers tours. » Si la deuxième tentative ne produit toujours pas de VERDICT, passer à l'examen manuel (secours de l'étape 8.5) et poster le VERDICT vous-même.

Portail d'examen de code final (après la DERNIÈRE tâche de l'idée vérifiée) : quand la tâche que vous viens 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 déployée — exécuter le portail d'examen de code de temps d'envoi avant de déclarer l'idée terminée. En ligne (pas de hook sur OpenClaw), même mécanisme que l'étape 8.5 : déclencher un sous-agent via sessions_spawn dont la task lui dit d'invoquer la compétence /code-reviewer contre l'idée (passer ideaUuid + numéro de round), et attendre ; le secours est un auto-examen en lecture seule suivant la procédure /code-reviewer. Il examine le changement de code agrégé de l'idée (intégration entre 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 → expédier ; FAIL → corriger via le workflow quick-dev (/quick-dev) : chorus_create_tasks avec proposalUuid défini à la proposition actuellement approuvée pour que les tâches de correction s'y attachent (ne pas rouvrir les anciennes tâches), puis exécuter → vérifier et re-exécuter le portail. Consultatif/comportemental. L'exécuter avant tout rapport d'achèvement d'idée.

Étape 9 : Gérer les retours de revue

Si le vérificateur retourne FAIL, ou 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érifier les retours :

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

2. Corriger chaque BLOCKER listé dans le commentaire FAIL du vérificateur.
3. S'enregistrer à nouveau (sous-agent), corriger les problèmes, signaler les corrections, soumettre à nouveau, et re-exécuter le vérificateur (Étape 8.5).

Étape 10 : Tâche terminée

Une fois que l'admin vérifie (statut: done), passer à la tâche disponible suivante (retour à l'étape 2).

Étape 11 : Rapport d'achèvement d'idée (consultatif)

Si la tâche que vous viens d'auto-vérifier était la DERNIÈRE de son idée (chaque tâche de chaque proposition approuvée est maintenant done/closed) et vous avez document:write, proposer d'appeler chorus_create_report. Sur OpenClaw, demander à l'utilisateur comme une invite en texte brut (par ex. « C'était la dernière tâche de l'idée. Voulez-vous que j'écrive un rapport d'achèvement ? Répondez oui/non. ») — il n'y a pas de primitive AskUserQuestion. La description de l'outil contient le modèle de section. Ignorer en cas de refus.

Session (Sous-agents uniquement)

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

1. chorus_create_session({ name }) — une seule 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. Passer sessionUuid à chorus_update_task et chorus_report_work pour l'attribution
4. chorus_session_checkout_task({ sessionUuid, taskUuid }) — quand terminé avec chaque tâche
5. chorus_close_session({ sessionUuid }) — quand le sous-agent a fini (aucun hook ne la ferme pour vous)

Pour garder une session longue active/visible, envoyer chorus_session_heartbeat({ sessionUuid }) périodiquement (tout outil accédant à la session la rafraîchit aussi).

Agent principal / Chef d'équipe : aucune session nécessaire — appeler les outils sans sessionUuid.

Exécution par vagues sur OpenClaw

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

Boucle de vague séquencielle

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

  if aucune tâche débloquée et toutes les tâches done/closed:
    break  # Tout est complet

  if aucune tâche débloquée mais quelques unes restent (pas done):
    break with escalation note  # bloquée — probablement une revue échouée bloquant le DAG

  # 2. Travailler chaque tâche débloquée vous-même, dans l'ordre :
  for each task in unblocked:
    chorus_claim_task({ taskUuid: task.uuid })
    chorus_update_task({ taskUuid: task.uuid, status: "in_progress" })
    # ... lire le contexte, implémenter, exécuter 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écuter le task-reviewer en ligne ; agir selon son VERDICT
    # Si vous avez task:admin, vérifier la tâche à "done" (ceci débloque les dépendants)

  # 3. Boucler — chorus_get_unblocked_tasks retourne maintenant la vague suivante

Critique : to_verify NE résout PAS les dépendances — seul 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épendants deviennent débloqués. Si vous n'avez pas task:admin, soumettre chaque tâche pour vérification et demander à l'admin du projet de vérifier entre les vagues, puis re-exécuter chorus_get_unblocked_tasks.

Optimisation réservée à Claude Code (se dégrade en séquentiel ici) : sous le plugin Claude Code, chaque vague peut être expédiée en parallèle via TeamCreate + sous-agents par tâche. OpenClaw n'a pas cette primitive, donc la boucle ci-dessus s'exécute en série. NE PAS essayer d'appeler TeamCreate sur OpenClaw — elle n'existe pas.

Optionnel : dispatch de sous-agent

Si votre hôte OpenClaw supporte bien le déclenchement de sous-agents workers (pas des Teams d'agents, juste des sous-agents génériques), vous pouvez en assigner un à chaque tâche. Parce qu'il n'y a pas de hook SubagentStart, l'invite du worker doit inclure les instructions de session manuelle explicitement :

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

La gestion de session est MANUELLE sur OpenClaw :
1. chorus_create_session({ name: "<worker-name>" }) -> conserver le sessionUuid
2. chorus_session_checkin_task({ sessionUuid, taskUuid })
3. chorus_update_task({ taskUuid, status: "in_progress", sessionUuid })
4. implémenter, 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 garde la propriété de la revue + vérification entre les vagues.

Accès MCP pour les sous-agents

Si vous dispatchez des sous-agents, assurez-vous qu'ils peuvent accéder au serveur Chorus MCP — la config du plugin (et donc les outils chorus__*) doit être disponible dans l'environnement du sous-agent, et la clé API doit avoir les permissions nécessaires.

Résolution de problèmes

Bonnes pratiques de rapport de travail

Bon rapport (permet la continuité de session) :

Implémenté le 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: flux de réinitialisation de mot de passe »
- PR : https://github.com/org/repo/pull/15

Détails d'implémentation :
- POST /api/auth/reset-request : envoie l'email avec jeton
- Le jeton expire après 1 heure, usage unique
- Limitation de débit : 3 requêtes/heure/email
- 12 nouveaux tests, tous passent

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

Mauvais rapport : Terminé.

Conseils

• Lire les commentaires de la tâche d'abord — ils contiennent les rapports de travail précédents pour la continuité de session
• Vérifier les dépendances en amont — lire les tâches dependsOn et leurs commentaires pour les interfaces/APIs
• Lire la proposition d'origine — comprendre la justification de conception et le DAG de tâche
• Utiliser commentCount — sauter la récupération de commentaires sur les entités avec un compte 0
• Signaler la progression fréquemment — inclure les chemins de fichiers, commits et PRs
• Écrire des résumés de soumission détaillés — l'Admin en a besoin pour vérifier
• Toujours exécuter le vérificateur en ligne après la soumission (Étape 8.5) — OpenClaw n'a pas de hook pour vous le rappeler
• Les sessions sont manuelles sur OpenClaw — créer, s'enregistrer/désenregistrer, et fermer votre propre session en tant que sous-agent
• Si bloqué, ajouter un commentaire et envisager de libérer la tâche
• Une tâche à la fois : terminer ou libérer avant d'en réclamer une autre

Quand libérer une tâche

Libérer si :

• Vous ne pouvez pas la terminer (connaissance manquante, bloquée)
• Une tâche de priorité plus élevée a besoin d'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 examine en utilisant /review
• Wake humain « 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 jusqu'à la fin via la compétence yolo (le pipeline AI-DLC en mode entièrement automatique), pas seulement l'étape d'exécution — lire l'état actuel de l'idée et reprendre depuis la phase où elle en est. Elle est adaptative aux étapes, 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