Skill Développement

Ce skill couvre l'étape de Développement du workflow AI-DLC : réclamer des tâches, écrire du code, rapporter la progression, soumettre pour vérification et gérer les sessions pour l'observabilité des workers.

Aperçu

Les Developer Agents prennent les tâches créées par les PM Agents (via le skill de proposition, skill_view("chorus:proposal")) et les transforment en code fonctionnel. Chaque tâche suit :

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

Pour l'exécution parallèle multi-agent, l'agent principal exécute les workers Chorus comme des enfants Hermes delegate_task, avec une session Chorus par worker pour l'observabilité.

Outils

Cycle de vie des tâches :

Rapports de travail :

Critères d'acceptation :

Session (les workers se connectent/déconnectent ; le Team Lead crée et ferme) :

Workers : toujours passer sessionUuid à chorus_update_task et chorus_report_work pour l'attribution. Agent principal / Team Lead travaillant une tâche lui-même : appeler ces outils sans sessionUuid — l'agent principal n'utilise pas de session.

Outils partagés (checkin, query, commentaire, recherche, notifications) : voir le skill d'aperçu chorus (skill_view("chorus:chorus"))

Workflow

Étape 1 : Pointage

chorus_checkin()

Vérifiez votre persona, vos affectations actuelles et les décomptes de travail en attente. Dans une session Hermes, le plugin Hermes Chorus a déjà exécuté ceci au premier tour (son hook pre_llm_call injecte ## Checkin, ## Spec Mode et ## Quick Reference) ; appelez-le à nouveau seulement si vous avez besoin de données à jour.

Étape 1.5 : Obtenir votre session (Workers uniquement)

Ignorez si vous êtes l'agent principal ou Team Lead.

Si vous êtes un worker (un enfant delegate_task), les sessions Chorus ne sont PAS créées automatiquement sur Hermes. Le Team Lead en a créé une pour vous et a mis son UUID dans votre context (cherchez une ligne Chorus session UUID:). Conservez-le pour toutes les opérations de tâche. Si votre context n'a pas d'UUID de session, travaillez sans — ne créez pas une session vous-même.

Étape 2 : Trouver du travail

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

Ou vérifiez les affectations existantes :

chorus_get_my_assignments()

Étape 3 : Réclamer une tâche

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

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

É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 utiles à lire.

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

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

   Prêtez 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. Vérifier 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>" })

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

4. Lire la proposition originale pour comprendre l'intention du design :

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

   (chorus_get_proposal par défaut à section: "basic" — métadonnées uniquement + index de brouillon. Passez section: "documents" pour les documents de design, 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>" })

Document update flow (Mode OpenSpec) : si la description de la proposition originale 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 spec avant de resoumetre), charger le skill openspec-aware (skill_view("chorus:openspec-aware")) et suivre §3.8 : éditer d'abord le fichier .md local, puis le refléter — préférer chorus mcp call … --arg-file content=<file> via terminal (voir skill_view("chorus:chorus-cli")); quand chorus n'est pas sur PATH, appeler l'outil MCP natif (mcp__chorus__chorus_pm_update_document) directement avec content lu du fichier via read_file. Arrêter sur toute erreur.

⛔ Ne pas appeler chorus_pm_update_document 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 brûle des tokens (openspec-aware §2 Rule 1).

Quand la DERNIÈRE tâche d'une idée OpenSpec est vérifiée, le plugin Hermes Chorus ajoute un rappel d'archivage au résultat chorus_admin_verify_task (openspec-aware §3.9) — exécuter openspec archive <slug> --yes, puis refléter chaque openspec/specs/<capability>/spec.md émis via §3.8.

Document update flow (mode spec-lite) : si la description de la proposition contient une ligne Spec-lite: .chorus/specs/<slug>/<YYYY-MM-DD>-<change-slug>/, les Documents PRD / tech_design / … du projet sont des miroirs des fichiers dans ce dossier daté. Pour mettre à jour un tel Document, charger le skill spec-lite (skill_view("chorus:spec-lite")) et suivre sa section Mirror : éditer d'abord le fichier <type>.md local, puis le refléter via chorus mcp call chorus_pm_update_document "{\"documentUuid\":\"<uuid>\"}" --arg-file content=<file> (documentUuid enregistré du frontmatter du fichier); quand chorus n'est pas sur PATH, appeler mcp__chorus__chorus_pm_update_document directement avec content lu du fichier via read_file. Arrêter sur erreur. Même règle ⛔ ne-pas-saisir-à-la-main-content que OpenSpec. Le durable .chorus/specs/<slug>/spec.md est édité en place aussi mais n'est jamais reflété (l'historique git est son enregistrement). Pas de flow archive — spec-lite n'a pas de CLI/validate/archive; à la livraison, définir simplement status: done dans spec.md.

En mode free-form sans OpenSpec, sans spec-lite (pas de ligne locator), éditer le contenu du Document directement via l'outil MCP existant, sans étape de fichier local.

Étape 5 : Commencer à travailler

Worker : se connecter d'abord à la tâche :

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

Puis marquer comme en cours :

# Worker:
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 (les tâches dependsOn ne sont pas en done ou closed), l'appel sera rejeté avec des informations de blocker détaillées. Utilisez chorus_get_unblocked_tasks pour trouver les tâches que vous pouvez démarrer maintenant.

Étape 6 : Rapporter la progression

Rapportez 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
• 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>"
})

Rapportez avec mise à jour du statut quand terminé :

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Implémentation complète:\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érification des 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 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, continuez à travailler jusqu'à pouvoir auto-vérifier comme passed. Utilisez failed seulement pour les critères optionnels hors de portée.

Étape 8 : Soumettre pour vérification

Workers — se déconnecter d'abord :

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

Puis soumettre :

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Feature d'authentification implémentée:\n- Endpoints login/logout ajoutés\n- Middleware JWT\n- 95% de couverture de test\n- Tous les AC auto-vérifiés (3/3 passed)"
})

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

Review Agent : Après chorus_submit_for_verify, le plugin Hermes Chorus ajoute un rappel au résultat de l'outil vous disant d'exécuter le chorus-task-reviewer — un revieweur indépendant en lecture seule. Vous DEVEZ l'exécuter vous-même (il n'est PAS lancé automatiquement). Les workers sautent ceci : le Team Lead revoit après le retour du batch de workers. Le reviewer s'exécute comme un enfant delegate_task sous la garde en lecture seule, donc il ne peut pas exécuter terminal; construisez d'abord le bundle de preuve, puis déléguez. delegate_task se bloque jusqu'à ce que le reviewer finisse. Le verdict est le commentaire que le reviewer poste sur la tâche, pas la valeur de retour de l'appel.

Construire le bundle de preuve (parent, via terminal; <base> est le point de branchement, ex. main) :

mkdir -p /tmp/chorus-review/<task-uuid>
git diff <base>...HEAD > /tmp/chorus-review/<task-uuid>/diff.patch
git log --oneline <base>..HEAD > /tmp/chorus-review/<task-uuid>/log.txt
<project test/build command> > /tmp/chorus-review/<task-uuid>/tests.txt 2>&1

Exécuter le task reviewer :

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>\nProject UUID: <project-uuid>\nMax review rounds: 3\nRepo: <abs repo path>\nEvidence: /tmp/chorus-review/<task-uuid>/diff.patch, /tmp/chorus-review/<task-uuid>/log.txt, /tmp/chorus-review/<task-uuid>/tests.txt",
)

Le marqueur [chorus-reviewer:task] DOIT être la première ligne du context (et devrait aussi être dans goal) — le plugin l'utilise pour mettre l'enfant en mode lecture seule. Les exemples de revieweur de proposition et de code sont dans le skill de review (skill_view("chorus:review"), Review Strategy).

Après que le reviewer finisse, lisez son VERDICT :

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

Trouvez le commentaire VERDICT: de CE round — celui posté après votre dispatch, pas un ancien round — et agissez dessus :

• VERDICT: PASS — Tous les AC vérifiés, pas de problèmes. Procédez à la vérification admin.
• VERDICT: PASS WITH NOTES — Tous les AC vérifiés, notes mineures. Procédez à la vérification admin (les notes ne bloquent pas).
• VERDICT: FAIL — BLOCKERs trouvés. Ne pas vérifier. Corrigez les BLOCKERs énumérés dans le commentaire du reviewer, puis resoumettez.

Si aucun nouveau commentaire VERDICT: n'apparaît après le retour du reviewer, vérifiez ce qu'il a POSTÉ. Un commentaire rapportant que la limite de rounds a été atteinte, ou tout autre refus explicite de revue, est une escalade délibérée à un humain : ARRÊTEZ — ne relancez pas, ne vous auto-reviewez pas, ne postez pas un VERDICT vous-même. S'il n'a rien posté du tout, relancez-le UNE FOIS, lui disant de rester dans son budget de tours et de réserver ses derniers tours pour le VERDICT, puis appliquez cette même vérification à ce que la nouvelle tentative poste. Un refus explicite de la nouvelle tentative signifie toujours ARRÊTEZ ; seul un second vrai silence vous permet de revenir la tâche vous-même en tant que pass en lecture seule en utilisant la checklist et POSTE le commentaire VERDICT. L'absence n'est jamais un PASS.

Final code-review gateway (après vérification de la DERNIÈRE tâche de l'Idea) : quand la tâche que vous venez de vérifier est la dernière tâche de sa proposition enracinée dans l'idea, la fonctionnalité est sur le point de se déployer — le plugin Hermes Chorus ajoute un rappel au résultat chorus_admin_verify_task d'exécuter chorus-code-reviewer (gated by CHORUS_ENABLE_CODE_REVIEWER, défaut activé). Exécutez-le vous-même en tant qu'enfant delegate_task avec le marqueur [chorus-reviewer:code] (exemple complet dans skill_view("chorus:review")), en passant ideaUuid + numéro de round et un bundle de preuve couvrant la feature entière (diff agrégé, log et sortie de test sur toutes les tâches de l'idea). Il revoit le changement de code agrégé de l'Idea sur toutes ses tâches (intégration inter-tâches, architecture, sécurité, régression, couverture au niveau de la feature) et poste un commentaire VERDICT sur l'idea. PASS / PASS WITH NOTES → déployer; FAIL → corriger via le skill quick-dev (skill_view("chorus:quick-dev")): chorus_create_tasks avec proposalUuid défini à la proposition approuvée actuelle pour que les tâches de correction s'y attachent — ne pas réouvrir les tâches vérifiées. Grouper les petits BLOCKERs connexes par défaut ; scinder seulement les corrections matériellement grandes ou indépendamment testables. Exiger l'auto-check AC, la review de tâche indépendante et la vérification admin pour chaque tâche de correction. Re-exécuter la review agrégée seulement après que chaque correction soit avec succès done; une correction échouée ou annulée arrête la boucle et escalade, limitée par CHORUS_MAX_CODE_REVIEW_ROUNDS (env, défaut 3; 0 = illimité). Consultatif/comportemental, comme les autres revieweurs. Exécutez-le avant tout rapport d'achèvement d'idea.

Étape 9 : Gérer les retours de review

Si le reviewer retourne FAIL, ou la tâche est réouverte après vérification :

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

1. Vérifiez les retours :

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

2. Corrigez tous les BLOCKERs énumérés dans le commentaire FAIL du reviewer.
3. Reconnecter-vous, corrigez les problèmes, rapportez les corrections, resoumettez.

Étape 10 : Tâche terminée

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

Étape 11 : Rapport d'achèvement d'Idea (consultatif)

Si la tâche que vous venez d'auto-vérifier était la DERNIÈRE d'une Idea (chaque tâche dans chaque proposition approuvée est maintenant done/closed) et que vous avez document:write, proposez d'appeler chorus_create_report. Dans une session interactive, posez la question à l'humain dans le chat (oui/non). Dans une session gateway (réveillée par Chorus) ou sans humain dans le chat, postez un chorus_add_comment sur l'Idea qui @mentionne le propriétaire (@[Name](user:<ownerUuid>) de chorus_checkin) demandant s'il faut écrire le rapport, puis terminez le tour et agissez sur la réponse quand réveillé. L'appel nécessite title (un titre de rapport court) plus content; la description du paramètre content porte le template de trois sections (## Summary / ## Decisions / ## Follow-ups). Ignorer si décliné — le plugin vous rappellera à la prochaine exécution.

Session (Workers uniquement)

Sur Hermes, les sessions Chorus pour les workers ne sont pas créées automatiquement. Le Team Lead possède le cycle de vie de la session :

1. Avant de déléguer, pour chaque worker : chorus_list_sessions() et réouvrir une session fermée avec le même nom de worker (chorus_reopen_session({ sessionUuid })), sinon chorus_create_session({ name: "<worker-name>" }).
2. Passer le sessionUuid dans le context de ce worker.
3. Après le retour de delegate_task, appeler chorus_close_session({ sessionUuid }) pour chaque session de worker du batch.

Les workers font seulement 3 choses avec la session :

1. chorus_session_checkin_task({ sessionUuid, taskUuid }) — avant de commencer le travail
2. chorus_session_checkout_task({ sessionUuid, taskUuid }) — quand terminé, avant chorus_submit_for_verify
3. Passer sessionUuid à chorus_update_task et chorus_report_work pour l'attribution

Les workers n'appellent jamais chorus_create_session ou chorus_close_session.

Agent principal / Team Lead : pas de session pour lui-même — appeler les outils sans sessionUuid.

Workers parallèles avec delegate_task

Utilisez Hermes delegate_task pour exécuter plusieurs workers Chorus en parallèle ; Chorus fournit une observabilité complète du travail via les sessions par worker.

Sémantique clé :

• Forme par batch. delegate_task(tasks=[{"goal": "...", "context": "..."}, ...]) exécute un enfant par entrée en parallèle. delegate_task(goal="...", context="...") exécute un seul enfant. La taille du batch est plafonnée par delegation.max_concurrent_children dans ~/.hermes/config.yaml; si un wave a plus de tâches prêtes que cela, scindez-le en plusieurs appels consécutifs.
• Bloquant. L'appel SE BLOQUE jusqu'à ce que tous les enfants du batch finissent, puis retourne le résumé final de chacun. Il n'y a pas de handle pour suivre et rien à fermer côté Hermes.
• Contexte isolé. Chaque enfant commence avec un contexte frais et ne sait rien de la conversation parent. Il hérite des toolsets du parent, incluant le serveur MCP Chorus. Mettez tout ce dont le worker a besoin dans context : UUID(s) de tâche, UUID de projet, chemin du repo, UUID de session Chorus, l'instruction de charger ce skill en premier, et toute décision de la conversation qui n'est pas enregistrée dans Chorus.

Architecture à deux couches

Workflow du Team Lead

# 1. Pointage et planification
chorus_checkin()
chorus_list_tasks({ projectUuid: "<project-uuid>" })
chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })

# 2. Une session Chorus par worker (réouvrir par nom si elle existe)
chorus_list_sessions()
s1 = chorus_create_session({ name: "worker-auth-api" })   # ou chorus_reopen_session
s2 = chorus_create_session({ name: "worker-auth-ui" })

# 3. Déléguer le wave entier en UN SEUL appel batch (scinder si au-dessus de max_concurrent_children)
delegate_task(tasks=[
  { "goal": "Implement Chorus task <task-uuid-1> and submit it for verification.",
    "context": "<worker context, see template below, with task-uuid-1 and s1.uuid>" },
  { "goal": "Implement Chorus task <task-uuid-2> and submit it for verification.",
    "context": "<worker context, see template below, with task-uuid-2 and s2.uuid>" },
])
# Se bloque jusqu'à ce que les deux workers finissent; retourne le résumé final de chaque worker.

# 4. Fermer chaque session de worker de ce batch
chorus_close_session({ sessionUuid: s1.uuid })
chorus_close_session({ sessionUuid: s2.uuid })

# 5. Revue + vérification de chaque tâche (task reviewer, puis chorus_admin_verify_task), puis wave suivante

Ce que le contexte du worker a besoin :

• UUID(s) de tâche + UUID de projet + chemin absolu du repo
• L'UUID de session Chorus créé pour ce worker
• L'instruction d'appeler skill_view("chorus:develop") en premier
• La boucle de worker (ci-dessous) et la règle d'arrêter après chorus_submit_for_verify
• Toute décision de conversation que le worker ne peut pas aller chercher dans Chorus

Worker Context Template

You are a Chorus worker. Your job is one Chorus task; the Chorus server is the source of truth.

First call skill_view("chorus:develop") and follow its worker steps.

Chorus task UUID: <task-uuid>
Project UUID: <project-uuid>
Repo: <abs repo path>
Chorus session UUID: <session-uuid>

Worker loop (pass sessionUuid to every call that accepts it):
1. chorus_session_checkin_task({ sessionUuid: "<session-uuid>", taskUuid: "<task-uuid>" })
2. chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress", sessionUuid: "<session-uuid>" })
3. Gather context (task, comments, upstream tasks, proposal documents), then implement, test, commit.
4. chorus_report_work({ taskUuid: "<task-uuid>", report: "<files, commits, tests>", sessionUuid: "<session-uuid>" })
5. chorus_report_criteria_self_check for every acceptance criterion.
6. chorus_session_checkout_task({ sessionUuid: "<session-uuid>", taskUuid: "<task-uuid>" })
7. chorus_submit_for_verify({ taskUuid: "<task-uuid>", summary: "..." })

Rules:
- Do NOT call chorus_create_session or chorus_close_session; the Team Lead owns the session.
- Do NOT run the task reviewer and do NOT verify; the Team Lead does both after you return.
- Notes from the Team Lead: <decisions from the conversation, constraints, files to avoid>.
- Your final message is returned to the Team Lead: list files changed, commits, test results, and AC status.

Worker Workflow

Le worker lit Chorus session UUID: de son context et exécute la boucle :

# 1. Se connecter à la tâche
chorus_session_checkin_task({ sessionUuid: "<my-session-uuid>", taskUuid: "<my-task-uuid>" })

# 2. Passer à in_progress
chorus_update_task({ taskUuid: "<my-task-uuid>", status: "in_progress", sessionUuid: "<my-session-uuid>" })

# 3. Faire du travail... code, test, commit...

# 4. Rapporter la progression
chorus_report_work({ taskUuid: "<my-task-uuid>", report: "...", sessionUuid: "<my-session-uuid>" })

# 5. Se déconnecter et soumettre
chorus_session_checkout_task({ sessionUuid: "<my-session-uuid>", taskUuid: "<my-task-uuid>" })
chorus_submit_for_verify({ taskUuid: "<my-task-uuid>", summary: "..." })

# Le message final du worker est retourné au Team Lead en tant que résumé delegate_task.
# NE PAS appeler chorus_close_session — le Team Lead le ferme après le retour de delegate_task.

Gérer les dépendances de tâche (DAG)

Respect côté serveur : chorus_update_task(status: "in_progress") rejette si toute tâche dependsOn n'est pas done ou closed.

Exécution par wave (recommandé) :

1. chorus_get_unblocked_tasks — trouver les tâches prêtes
2. Créer (ou réouvrir) une session Chorus par tâche prête, puis exécuter le wave en tant qu'un seul batch delegate_task(tasks=[...]) (scinder en plusieurs appels au-dessus de delegation.max_concurrent_children). L'appel retourne quand tous les workers ont finisé (chaque tâche à to_verify).
3. Fermer chaque session de worker (chorus_close_session).
4. Vérifier chaque tâche — construire son bundle de preuve, exécuter chorus-task-reviewer (Étape 8), agir sur son VERDICT, puis chorus_admin_verify_task → done.
5. chorus_get_unblocked_tasks — trouver les tâches nouvellement déverrouillées (Wave 2)
6. Répéter jusqu'à ce que toutes les tâches soient done

Critique : to_verify ne résout PAS les dépendances — seul done ou closed le fait. Le Team Lead doit vérifier les tâches entre les waves.

Plusieurs tâches par worker

Un seul worker peut gérer plusieurs tâches séquentiellement — un enfant delegate_task avec une liste ordonnée :

delegate_task(
  goal="Implement Chorus tasks <task-schema-uuid> then <task-api-uuid>, in order.",
  context="You are a Chorus worker.\nFirst call skill_view(\"chorus:develop\") and follow its worker steps.\nYour Chorus tasks (work in order):\n1. <task-schema-uuid>\n2. <task-api-uuid> (depends on #1)\nProject UUID: <project-uuid>\nRepo: <abs repo path>\nChorus session UUID: <session-uuid>\n\nFor EACH task: checkin -> in_progress -> work -> report -> checkout -> submit_for_verify",
)

Notez que la tâche #2 ne peut pas passer à in_progress tant que la tâche #1 n'est pas done, ce qui nécessite la vérification du Team Lead. Chaînez seulement les tâches dépendantes dans un worker quand le Team Lead vérifie entre elles, ou scindez-les en waves séparés.

Accès MCP pour les workers

Les enfants delegate_task héritent des toolsets du parent, donc ils reçoivent le même serveur MCP chorus que le parent. Si le parent n'a pas les outils Chorus, corriger d'abord la configuration MCP : installer le paquet chorus-mcp (loopback http://localhost:8637/api/mcp, header Authorization: Bearer ${CHORUS_API_KEY}), ou pour tout autre déploiement exécuter chorus agents add --agents hermes ou configurer mcp_servers.chorus.url / mcp_servers.chorus.headers.Authorization avec hermes config set. Les identifiants proviennent de CHORUS_URL / CHORUS_API_KEY ou ~/.hermes/.env. Redémarrer Hermes après configuration.

Dépannage

Meilleures pratiques de rapport de travail

Bon rapport (permet la continuité de session) :

Implemented password reset flow:

Files created/modified:
- src/services/auth.service.ts (new)
- src/app/api/auth/reset/route.ts (new)
- tests/auth/reset.test.ts (new)

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

Implementation details:
- POST /api/auth/reset-request: sends email with token
- Token expires after 1 hour, single-use
- Rate limiting: 3 requests/hour/email
- 12 new tests, all passing

Acceptance criteria:
- [x] User can request reset via email
- [x] Reset link expires after 1 hour
- [x] Rate limiting prevents abuse

Mauvais rapport : Done.

Conseils

• Lire les commentaires de 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/API
• Lire la proposition originale — comprendre la logique du design et le DAG de tâche
• Utiliser commentCount — ignorer la récupération de commentaires sur les entités avec count 0
• Rapporter la progression fréquemment — inclure les chemins de fichiers, commits et PR
• Écrire des résumés de soumission détaillés — Admin en a besoin pour vérifier
• Si bloqué, ajouter un commentaire et envisager de libérer la tâche
• Une tâche à la fois : finir ou libérer avant d'en réclamer une autre
• Utiliser des noms de worker significatifs — ils deviennent des noms de session Chorus

Quand libérer une tâche

Libérer si :

• Vous ne pouvez pas la terminer (connaissance manquante, blocage)
• Une tâche plus prioritaire 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: "Releasing: reason..." })

Suivant

• Après soumission pour vérification, un Admin revoit en utilisant le skill de review (skill_view("chorus:review"))
• Human "Start Development" wake : une wake start_development (l'humain a cliqué Start Development sur le panneau de détail d'idea) signifie : réclamer et exécuter TOUTES les tâches restantes de la proposition approuvée de l'idea dans l'ordre des dépendances — boucler ce workflow jusqu'à ce qu'aucune tâche réclamable ne reste, laissant les tâches to_verify et autres-sessions intactes.
• Human "Yolo" wake : une wake yolo_requested (l'humain a cliqué Yolo sur le panneau de détail d'idea) signifie : piloter l'ENTIRE idea à done via le skill yolo (skill_view("chorus:yolo"), le pipeline AI-DLC entièrement automatique), pas seulement la phase d'exécution — lire l'état actuel de l'idea et reprendre depuis la phase où elle est. Contrairement à start_development, c'est adaptatif par étape, et il ne doit jamais fusionner ou pousser une PR sans approbation explicite de l'humain.
• Pour l'aperçu de plateforme et les outils partagés, voir skill_view("chorus:chorus")