Compétence Yolo

Pipeline IA-DLC entièrement automatisé. L'utilisateur fournit un prompt ; l'agent gère tout le cycle de vie : Idée -> Élaboration -> Proposition -> Revue -> Exécution -> Vérification -> Terminé.

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

Adaptations dsh résumées (détails inline ci-dessous) : (1) l'élaboration s'auto-répond sans interaction utilisateur ; (2) les relecteurs s'exécutent inline après chaque envoi en chargeant le relecteur exact via l'outil skill dans un subagent au premier plan (run_in_background: false, attendre le verdict), avec un repli d'auto-revue en lecture seule ; (3) les sessions sont manuelles si vous dispatchez des sous-agents ; (4) l'exécution des tâches utilise des vagues séquentielles de l'agent principal.

Vue d'ensemble

yolo-chorus automatise le flux de travail IA-DLC complet. Vous fournissez une description en langage naturel de ce que vous voulez construire, et l'agent gère tout :

1. Planification -- créer projet, idée, auto-élaboration, proposition avec docs et tâches
2. Revue de proposition -- boucle adversariale proposition-relecteur
3. Exécution -- exécution séquentielle et ordonnée par dépendances des tâches par l'agent principal
4. Vérification -- boucle adversariale tâche-relecteur + vérification admin
5. Rapport -- résumé d'achèvement

/yolo <prompt>
       |
       v
  Projet + Idée + Élaboration (auto-répondue) + Proposition
       |
       v
  Relecteur de proposition (inline, jusqu'à maxProposalReviewRounds)
       |
       v
  Approbation Admin --> Les tâches se matérialisent
       |
       v
  Exécution par vagues séquentielles (agent principal : boucle chorus_get_unblocked_tasks)
       |  (implémenter tâche + relecteur tâche par tâche)
       v
  Vérification Admin de chaque tâche --> débloquer la suivante
       |
       v
  Terminé. Résumé du rapport.

Échappatoire : interrompez à tout moment. Toutes les entités créées (projet, idée, proposition, tâches) persistent dans Chorus. Reprenez manuellement via develop-chorus ou review-chorus.

Prérequis

La clé API a besoin de droits write + admin sur chaque ressource qu'elle touche :

Vérifier au démarrage :

perms = chorus_checkin().agent.permissions
need = { idea: ["write"], proposal: ["write","admin"],
         task: ["write","admin"], project: ["write"] }

for resource, actions in need:
  missing = [a for a in actions if a not in (perms[resource] or [])]
  if missing: ABORT "/yolo needs {resource}: {missing}. Use an Admin-preset API key."

Entrée

/yolo <prompt en langage naturel>
/yolo <prompt> --project <project-uuid>

• <prompt> -- ce que vous voulez construire (devient le contenu de l'Idée)
• --project <uuid> -- optionnel ; utiliser un projet existant à la place d'en créer un nouveau

Flux de travail

Phase 1 : Planification

Étape 1.1 : Résoudre le projet

Analysez les arguments pour --project <uuid>.

Si --project est fourni :

chorus_get_project({ projectUuid: "<uuid>" })

Vérifiez qu'il existe et continuez.

S'il n'est pas fourni, recherchez d'abord un projet existant approprié :

# 1. Rechercher des projets correspondant au sujet du prompt
chorus_search({ query: "<key terms from prompt>", entityTypes: ["project"] })

# 2. Ou lister les projets récents pour trouver une correspondance
chorus_list_projects()

Examinez les résultats. Si un projet correspond clairement à l'intention de l'utilisateur (même sujet, actif, portée pertinente), utilisez-le. Si aucun projet approprié n'existe, créez-en un nouveau :

chorus_admin_create_project({
  name: "<short title derived from prompt>",
  description: "<1-2 sentence summary of the prompt>"
})

Étape 1.2 : Créer une idée

chorus_pm_create_idea({
  projectUuid: "<project-uuid>",
  title: "<concise title derived from prompt>",
  content: "<full user prompt as-is>"
})

Puis la revendiquer :

chorus_claim_idea({ ideaUuid: "<idea-uuid>" })

Étape 1.3 : Auto-élaboration

En mode /yolo, l'agent génère des questions d'élaboration et y répond lui-même -- aucune interaction utilisateur du tout. Quand CHORUS_DAEMON_HEADLESS=1, ask_user_question est interdite, et yolo délibérément ne pose pas de question à l'utilisateur ; il s'auto-répond pour conserver une piste d'audit sans interrompre l'exécution.

L'auto-élaboration est toujours une boucle. Si répondre à vos propres questions met au jour une nouvelle question, contradiction ou lacune, revenez à chorus_pm_start_elaboration pour une autre ronde auto-répondue avant de résoudre — ne forcez pas une résolution sur de l'ambiguïté non résolue. Il n'y a pas de gate humain dans YOLO, donc la boucle s'arrête sur votre jugement qu'aucun point matériel n'est laissé ouvert (cap de 10 rondes). Les étapes 1–2 constituent une ronde ; répétez-les au besoin, puis résolvez une fois à l'étape 3.

1. Générer et soumettre des questions :

   chorus_pm_start_elaboration({
     ideaUuid: "<idea-uuid>",
     depth: "standard",
     questions: [
       {
         id: "q1",
         text: "<question about scope, architecture, etc.>",
         category: "functional",
         options: [
           { id: "a", label: "<option A>" },
           { id: "b", label: "<option B>" }
         ]
       }
       // ... 5-8 questions covering functional, technical, scope aspects
     ]
   })

2. Répondre immédiatement (l'agent sélectionne les meilleures options selon le prompt — aucun prompt utilisateur) :

   chorus_answer_elaboration({
     ideaUuid: "<idea-uuid>",
     roundUuid: "<round-uuid>",
     answers: [
       { questionId: "q1", selectedOptionId: "a", customText: "Rationale: ..." },
       // ...
     ]
   })

3. Résoudre — en mode YOLO l'agent résout l'élaboration de manière autonome, sans gate de confirmation humaine (l'exigence de confirmation humaine qui s'applique au flux interactif idea-chorus est explicitement levée dans l'automation yolo-chorus) :

   chorus_pm_validate_elaboration({
     ideaUuid: "<idea-uuid>"
   })

   chorus_pm_validate_elaboration nécessite idea:admin. yolo-chorus mandate déjà une clé Admin-preset dans les Prérequis, ceci est donc satisfait. Pour ouvrir une autre ronde d'auto-élaboration au lieu de résoudre, appelez simplement chorus_pm_start_elaboration à nouveau.

Étape 1.4 : Créer une proposition

1. Détecter le mode OpenSpec (inline). Chargez la compétence openspec-aware-chorus et exécutez sa §1 détection en trois vérifications inline (CHORUS_OPENSPEC_MODE != "off", un répertoire openspec/ à la racine du projet, et la CLI openspec sur PATH).

   Note dsh : il n'y a pas de hook Claude Code SessionStart pour précomputer CHORUS_OPENSPEC_ACTIVE. Vous devez exécuter vous-même les trois vérifications, inline, ici. C'est obligatoire — yolo s'exécute sans surveillance, donc choisir silencieusement le mauvais mode est exactement le scénario d'échec que le contrat de détection existe pour prévenir.

   • Les trois vérifications passent → branche pilotée par spécifications (sous-étape 2a ci-dessous).
   • Toute vérification échoue (ou CHORUS_OPENSPEC_MODE=off) → branche libre (sous-étape 2b ci-dessous).

2. Créer le conteneur de proposition vide. En mode OpenSpec, la description DOIT contenir la ligne littérale OpenSpec change slug: <slug> (utilisez le $SLUG que vous choisirez en 2a) ; en mode libre, omettez cette ligne.

   chorus_pm_create_proposal({
     projectUuid: "<project-uuid>",
     title: "<feature name>",
     description: "<summary>\n\nOpenSpec change slug: <slug>",   // Mode OpenSpec
     // description: "<summary>",                                 // Mode libre
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   })

   Puis branchez :

   2a. Mode OpenSpec (les trois vérifications passent). Suivez openspec-aware-chorus §3 de bout en bout :

   • Choisissez $SLUG, exécutez openspec new change "$SLUG" (§3.1–§3.2).
   • Créez proposal.md, design.md, et un specs/<capability>/spec.md par capacité localement sur disque (§3.3). ADDED Requirements uniquement ; repli par spécification à Markdown libre si MODIFIED/REMOVED est nécessaire.
   • Définissez les aides json_encode_file, chorus_check_response (§3.4, §6).
   • Miroir chaque fichier local via "$CHORUS_MCP_CALL" chorus_pm_add_document_draft "$PAYLOAD" (§3.6) — un appel par fichier, avec le type de document de openspec-aware-chorus §5.

   ⛔ Ne pas invoquer chorus_pm_add_document_draft / chorus_pm_update_document_draft / chorus_pm_update_document depuis le harness MCP avec un champ content saisi à la main dans cette branche. Retyper le corps markdown gaspille 20k+ tokens par proposition et casse l'égalité des octets avec les fichiers locaux. Voir openspec-aware-chorus §2 Règle 1.

   Continuez ensuite à l'étape 3 (brouillons de tâches).

   2b. Mode libre (toute vérification échoue). Ajoutez un brouillon de document de conception technique directement via MCP, contenu créé inline :

   chorus_pm_add_document_draft({
     proposalUuid: "<proposal-uuid>",
     type: "tech_design",
     title: "Tech Design: <feature>",
     content: "<markdown tech design covering architecture, data model, API, module contracts>"
   })

3. Ajouter des brouillons de tâches de manière incrémentielle (utilisez le draftUuid retourné pour l'enchaînement des dépendances). acceptanceCriteriaItems est obligatoire sur chaque brouillon — au moins un critère non vide, ou l'appel est rejeté :

   # Première tâche
   result1 = chorus_pm_add_task_draft({
     proposalUuid: "<proposal-uuid>",
     title: "<module name>",
     description: "<what to build, referencing tech design>",
     priority: "high",
     storyPoints: 3,
     acceptanceCriteriaItems: [
       { description: "<testable criterion>", required: true },
       // ...
     ]
   })
   
   # Deuxième tâche, dépend de la première
   chorus_pm_add_task_draft({
     proposalUuid: "<proposal-uuid>",
     title: "<dependent module>",
     description: "...",
     priority: "medium",
     storyPoints: 2,
     acceptanceCriteriaItems: [...],
     dependsOnDraftUuids: ["<result1.draftUuid>"]
   })

4. Valider :

   chorus_pm_validate_proposal({ proposalUuid: "<proposal-uuid>" })

   Corriger toute erreur, puis continuer.

5. Soumettre :

   chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })

   Procédez immédiatement à la Phase 2 et exécutez le relecteur de proposition inline — dsh n'a pas de hook PostToolUse pour vous le rappeler.

Phase 2 : Boucle de revue de proposition

Différence dsh : il n'y a pas de hook PostToolUse injectant un rappel « générer le relecteur ». Exécutez le relecteur inline, juste après chorus_pm_submit_proposal.

Obtenez un VERDICT indépendant sur la proposition :

• Préféré — générer un sous-agent relecteur (au premier plan). Utilisez l'outil dsh subagent pour générer un sous-agent avec run_in_background: false (premier plan — l'appel attend et retourne le résultat inline ; la décision d'approbation/rejet dépend du verdict) dont la tâche lui dit d'appeler l'outil skill avec proposal-reviewer-chorus, puis de revoir la proposition. Le résultat autoritaire est le commentaire le plus récent VERDICT: sur la proposition. Définissez run_in_background: true (un sous-agent continuable/d'arrière-plan dont vous collectez l'avis de règlement plus tard) uniquement quand vous voulez délibérément vous étendre et que vous n'avez pas besoin du verdict avant votre prochaine étape.

  Load and run the proposal-reviewer-chorus skill to review proposalUuid <uuid>. This is review round <N>. Read the proposal, its documents, the idea, and the elaboration; classify findings as BLOCKER/NOTE; post your VERDICT comment on the proposal when done.

• Repli — le revoir vous-même. Si subagent n'est pas disponible (p. ex. génération désactivée par politique), faites la revue vous-même en tant que passage focalisé et en lecture seule suivant la procédure de la compétence proposal-reviewer-chorus (lire proposition + commentaires + idée + élaboration ; vérifier complétude doc, granularité tâche, couverture AC↔exigence, le DAG, et points d'intégration ; classer BLOCKER/NOTE) et enregistrez le résultat via chorus_add_comment finissant par une ligne VERDICT:. Ne modifiez pas les brouillons lors du passage de revue.

Puis :

1. Lisez le VERDICT du relecteur :

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

   Cherchez le commentaire le plus récent contenant VERDICT:.

2. Agissez sur le VERDICT :

   • PASS ou PASS WITH NOTES --

     chorus_admin_approve_proposal({
       proposalUuid: "<proposal-uuid>",
       reviewNote: "PASS from reviewer. <brief summary of notes if any>"
     })

     Les tâches et documents se matérialisent automatiquement. Continuez à la Phase 3.

   • FAIL -- Lisez les BLOCKERs depuis le commentaire du relecteur. Puis :

     chorus_pm_reject_proposal({
       proposalUuid: "<proposal-uuid>",
       reviewNote: "FAIL from reviewer. Fixing BLOCKERs: <list>"
     })

     Révisez les brouillons (chorus_pm_update_document_draft, chorus_pm_update_task_draft) pour traiter chaque BLOCKER, puis resoumettez :

     chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })

     Après la resoumission, exécutez le relecteur inline à nouveau pour la Ronde 2 (idem ci-dessus).

3. Rondes max : Bouclez jusqu'à maxProposalReviewRounds (depuis la config du plugin, par défaut 3). Si épuisé :

   STOP: "Proposal review failed after {maxRounds} rounds.
          Remaining BLOCKERs: <list>. Human review needed.
          Proposal UUID: <uuid>"

4. Pas de nouveau commentaire VERDICT après le retour du relecteur généré ? Il a épuisé son budget de tours. Regénérez-le UNE FOIS avec un indice de budget concis : « Stay within turn budget. Skip deep source verification. Fetch proposal + comments + idea only, skim for obvious BLOCKERs, and post your VERDICT within the first 10 turns. » Si toujours pas de VERDICT, revenez à une revue manuelle et postez le VERDICT vous-même — le pipeline ne peut pas boucler indéfiniment sur un relecteur silencieux.

Phase 3 : Exécution des tâches (Vagues séquentielles)

Après approbation de la proposition, les tâches existent en statut open. Exécutez-les dans des vagues ordonnées par dépendances.

Différence dsh : dsh n'a pas de primitif Agent Teams / TeamCreate. Exécutez les vagues séquentiellement en tant qu'agent principal : boulez chorus_get_unblocked_tasks, implémentez vous-même chaque tâche prête, vérifiez-la, puis boulez à nouveau pour la prochaine vague. N'appelez PAS TeamCreate — elle n'existe pas sur dsh. (Sous le plugin Claude Code, chaque vague peut être dispatchée en parallèle via TeamCreate ; c'est une optimisation Claude-Code uniquement qui se dégrade à la boucle séquentielle ici.)

wave = 1

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

  if no unblocked tasks and all tasks done/closed:
    break  # Tous complets

  if no unblocked tasks and some tasks not done:
    # Bloqué -- les tâches ont échoué la revue et ne peuvent pas continuer
    break with escalation report

  # 2. Implémenter chaque tâche débloquée, dans l'ordre, EN TANT QU'AGENT PRINCIPAL :
  for each task in unblocked:
    chorus_claim_task({ taskUuid: task.uuid })
    chorus_update_task({ taskUuid: task.uuid, status: "in_progress" })

    # ... lire tâche + proposition + documents projet pour le contexte,
    #     écrire code, exécuter tests ...

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

    # 3. Procéder à la Phase 4 (vérification) pour CETTE tâche avant de passer à la suivante.

  wave += 1

Dispatch optionnel de sous-agent : si votre hôte dsh supporte les sous-agents workers génériques (pas Agent Teams), vous pouvez confier une tâche à la fois à un sous-agent. Parce qu'il n'y a pas de hook SubagentStart, le prompt du worker doit inclure explicitement les instructions de session manuelles — voir develop-chorus « Optional: sub-agent dispatch ». L'agent principal possède toujours la revue + vérification. Ceci ne change pas la structure séquentielle, vague après vague ci-dessus.

Phase 4 : Vérification

Après que chaque tâche soit soumise (Phase 3 étape 3), vérifiez-la avant de continuer :

for the just-submitted task:
  # 1. Vérifier le statut de la tâche
  task = chorus_get_task({ taskUuid: "<task-uuid>" })

  if task.status != "to_verify":
    # l'implémentation peut avoir échoué ; traiter ou ignorer
    continue

  # 2. Exécuter le relecteur de tâche INLINE (pas de hook sur dsh) :
  #    - Préféré : utiliser l'outil subagent pour générer un sous-agent avec run_in_background:false (premier plan, attendre le verdict) dont la
  #      tâche dit : « Call the skill tool with task-reviewer-chorus, verify taskUuid
  #      <uuid> (round <N>), and post the VERDICT comment. » Laissez-le finir, puis
  #      lisez le commentaire VERDICT le plus récent sur la tâche.
  #    - Repli (subagent non disponible) : la revoir vous-même en tant que passage focalisé en lecture seule
  #      suivant la procédure task-reviewer-chorus (lire tâche + proposition + docs + code,
  #      exécuter tests en lecture seule, classer les résultats BLOCKER/NOTE) et poster le VERDICT via
  #      chorus_add_comment.

  # 3. Lire VERDICT du relecteur de tâche
  comments = chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
  # Trouver le commentaire le plus récent contenant « VERDICT: »

  # 4. Agir sur VERDICT — trois résultats possibles :
  if VERDICT is "PASS":
    chorus_mark_acceptance_criteria({
      taskUuid: "<task-uuid>",
      criteria: [
        { uuid: "<ac-uuid>", status: "passed", evidence: "<from reviewer>" },
        // ...
      ]
    })
    chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
    # La tâche est maintenant « done » -- débloque les dépendants pour la prochaine vague

  if VERDICT is "PASS WITH NOTES":
    chorus_mark_acceptance_criteria({ ... })
    chorus_admin_verify_task({ taskUuid: "<task-uuid>" })

  if VERDICT is "FAIL":
    # BLOCKERs trouvés. Ne VÉRIFIEZ PAS. Réouvrez pour révision.
    chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
    # Corriger les BLOCKERs lors d'une future passe (la tâche revient à in_progress/open)

Après vérification des tâches de la vague, revenez à la boucle de Phase 3 pour lever les tâches nouvellement débloquées. Souvenez-vous : seul done (pas to_verify) débloque les dépendants.

Rondes max par tâche : Suivi par maxTaskReviewRounds depuis la config du plugin (par défaut 3). Si une tâche a été réouverte maxRounds fois, ignorez-la et signalez l'escalade humaine :

ESCALATE: "Task '{title}' failed review after {maxRounds} rounds.
           Last BLOCKERs: <list>. Manual intervention needed.
           Task UUID: <uuid>"

Continuez avec les tâches restantes -- n'arrêtez pas tout le pipeline pour une tâche bloquée.

Pas de nouveau commentaire VERDICT après le retour du relecteur de tâche généré ? Il a épuisé son budget de tours. Regénérez-le UNE FOIS avec un indice de budget concis : « Stay within turn budget. Skip deep verification. Fetch task/proposal/comments, run only the core tests, and post your VERDICT within the first 12 turns. » Si toujours pas de VERDICT, revenez à une revue manuelle et postez le VERDICT vous-même — ne bouclez pas indéfiniment.

Phase 4.5 : Gate de revue de code (obligatoire pré-livraison)

Une fois que chaque tâche de la proposition de l'idée est vérifiée (done) — la Phase 3 ne trouve plus de tâches débloquées et aucune ne reste non-terminale — exécutez le gate final de revue de code au moment de la livraison avant le rapport d'achèvement de Phase 5b. Il examine le changement de code agrégé de l'Idée entière sur toutes les tâches (pas une seule tâche) et poste son verdict sur l'idée. Inline (pas de hook sur dsh), même mécanisme que Phase 4 :

• Préféré — générer un sous-agent relecteur (au premier plan). Utilisez subagent pour générer un sous-agent avec run_in_background: false (premier plan — l'appel attend et retourne le verdict inline ; la décision de livraison en dépend ; ne détachez PAS — définissez run_in_background: true uniquement pour délibérément vous étendre) dont la task lui dit d'appeler l'outil skill avec code-reviewer-chorus et de le suivre contre l'idée. Exemple de prompt de tâche : Load and run the code-reviewer-chorus skill to review the aggregate code for ideaUuid <uuid> (round <N>); post your VERDICT comment on the idea when done.
• Repli — le revoir vous-même. Si subagent n'est pas disponible, effectuez la revue en tant que passage focalisé en lecture seule suivant la procédure code-reviewer-chorus (lire l'idée, ses propositions approuvées + documents + tâches ; inférer le diff agrégé des rapports de tâches + git log/diff; revoir intégration inter-tâches, architecture, sécurité, régression, couverture au niveau de la fonctionnalité ; exécuter la compilation/test du projet) et postez le commentaire VERDICT: sur l'idée vous-même.

Agissez sur le VERDICT :

• PASS / PASS WITH NOTES — la fonctionnalité est autorisée à être livrée. Continuez à Phase 5 / 5b.
• FAIL — ne livrez PAS. Lisez les BLOCKERs, puis corrigez-les via le flux quick-dev (quick-dev-chorus) : appelez chorus_create_tasks avec proposalUuid défini à la proposition approuvée actuelle pour que les tâches de correction s'y attachent — ne rouvrez pas les tâches déjà vérifiées ni n'appliquez des corrections non suivies. Groupez les petits BLOCKERs liés dans une tâche cohésive unique par défaut ; divisez uniquement les corrections matériellement grandes ou indépendamment testables. Pilotez chaque tâche de correction à travers Phase 3 → Phase 4, incluant vérification AC auto-contrôle, revue de tâche indépendante, et vérification admin. Réexécutez le gate uniquement après que chaque tâche de correction soit avec succès done ; une tâche de correction échouée ou annulée, arrêtez la boucle automatique et escaladez. Boucle bornée par maxCodeReviewRounds (par défaut 3 ; 0 = illimité).

ESCALATE: "Idea '{title}' failed code review after {maxCodeReviewRounds} rounds.
           Last BLOCKERs: <list>. Manual intervention needed. Idea UUID: <uuid>"

Pas de commentaire VERDICT après le retour du relecteur de code ? Il a épuisé son budget de tours (plus grand que celui du relecteur de tâche car il examine la fonctionnalité entière). Regénérez UNE FOIS avec un indice de budget concis ; si toujours silencieux, revenez à une passe manuelle en lecture seule et postez le VERDICT vous-même.

Le gate est comportemental comme les deux autres relecteurs : son verdict est consultatif et ne change pas le statut stocké de l'Idée ; l'orchestrateur le respecte. Il s'exécute avant le rapport d'achèvement pour que le rapport ne soit jamais écrit quand un FAIL est en attente.

Phase 5 : Rapport

Après achèvement de toutes les vagues, sortez un résumé markdown :

## /yolo Complete

**Project:** <project-name> (<project-uuid>)
**Proposal:** <proposal-title> (<proposal-uuid>)
**Idea:** <idea-title> (<idea-uuid>)

### Tasks
| Task | Status | Review Rounds |
|------|--------|---------------|
| <title> | done | 1 |
| <title> | done | 2 |
| <title> | ESCALATED | 3 (max) |

### Summary
- Total tasks: N
- Completed: X / N
- Escalated: Y (need human review)
- Waves executed: W

Phase 5b : Rapport d'achèvement de l'idée (obligatoire)

Une exécution réussie de yolo-chorus termine toujours l'Idée — appelez chorus_create_report une fois avec proposalUuid défini à la dernière proposition vérifiée. Le paramètre content porte le modèle de section ; suivez-le. Surfacez le documentUuid retourné dans le résumé de Phase 5. Ignorer c'est violer le protocole.

Ordre : écrivez le rapport d'achèvement uniquement après que le gate de revue de code Phase 4.5 retourne PASS / PASS WITH NOTES — jamais quand un code-review FAIL est en attente.

Archive OpenSpec : si vous avez exécuté en mode OpenSpec (branche d'étape 1.4 2a), la dernière tâche vérifiée déclenche aussi le flux d'archive. dsh n'a pas de hook PostToolUse pour vous le rappeler — après vérification de la tâche finale, exécutez openspec-aware-chorus §3.9 vous-même (openspec archive <slug> --yes, puis miroir chaque openspec/specs/<capability>/spec.md émis via §3.8).

Gestion des erreurs

Conseils

• Gardez le prompt initial détaillé -- plus vous fournissez de contexte, meilleure est la qualité de la proposition auto-générée
• Le relecteur de proposition est votre gate de qualité -- s'il continue à FAILer, le prompt peut être trop vague
• Surveillez le nombre de vagues -- si les tâches continuent à être réouvertes, considérez l'arrêt et la revue manuelle du feedback
• Toute piste d'audit est conservée : Q&A élaboration, VERDICTs relecteurs, rapports de travail. Vérifiez l'interface Chorus pour l'historique complet
• Pour les petites/tâches simples, considérez quick-dev-chorus à la place -- elle saute les frais généraux Idée->Proposition
• Les sous-agents (si vous en dispatchez) partagent votre clé API ; assurez-vous qu'elle a les permissions listées dans Prérequis avant de commencer

Suivant

• Pour revoir manuellement les propositions : review-chorus
• Pour développer manuellement les tâches : develop-chorus
• Pour créer rapidement des tâches autonomes : quick-dev-chorus
• Pour aperçu de plateforme : chorus