Yolo Skill

Pipeline d'IA-DLC entièrement automatisé. L'utilisateur fournit un prompt ; l'agent pilote l'intégralité du cycle de vie : Idée -> Élaboration -> Proposition -> Examen -> 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 chorus__ sur OpenClaw (par exemple chorus__chorus_pm_create_proposal). Les noms simples sont utilisés ci-dessous par souci de lisibilité — ajoutez le préfixe chorus__ lors de l'invocation. Voir /chorus pour la règle complète.

Adaptations OpenClaw résumées (détails en ligne ci-dessous) : (1) l'élaboration est auto-répondue en texte brut — pas de AskUserQuestion, pas d'interaction utilisateur ; (2) les examinateurs fonctionnent en ligne après chaque soumission — générez un sous-agent avec l'outil OpenClaw sessions_spawn et dites-lui d'exécuter la skill /proposal-reviewer ou /task-reviewer, avec un auto-examen en lecture seule en secours quand sessions_spawn n'est pas disponible ; (3) les sessions sont manuelles si vous distribuez des sous-agents (pas de hook SubagentStart) ; (4) l'exécution des tâches est des vagues d'agent principal séquentielles — OpenClaw n'a pas de primitive Agent Teams / TeamCreate.

Aperçu

/yolo automatise le workflow complet d'IA-DLC. 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 & tâches
2. Examen de la proposition -- boucle adversariale proposal-reviewer
3. Exécution -- exécution séquentielle des tâches ordonnées par dépendances par l'agent principal
4. Vérification -- boucle adversariale task-reviewer + admin verify
5. Rapport -- résumé d'accomplissement

/yolo <prompt>
       |
       v
  Projet + Idée + Élaboration (auto-répondue) + Proposition
       |
       v
  Proposal Reviewer (en ligne, jusqu'à maxProposalReviewRounds)
       |
       v
  Admin Approve --> Les tâches se matérialisent
       |
       v
  Exécution séquentielle des vagues (agent principal : boucle chorus_get_unblocked_tasks)
       |  (implémenter tâche + task-reviewer par tâche)
       v
  Admin Verify chaque tâche --> déverrouille la suivante
       |
       v
  Terminé. Résumé du rapport.

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

Prérequis

La clé API doit avoir l'accès en écriture + administrateur pour 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 <uuid-projet>

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

Workflow

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 procédez.

Si non fourni, recherchez d'abord un projet existant approprié :

# 1. Rechercher des projets correspondant au sujet du prompt
chorus_search({ query: "<termes clés du 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 convenable n'existe, créez-en un :

chorus_admin_create_project({
  name: "<titre court dérivé du prompt>",
  description: "<résumé de 1-2 phrases du prompt>"
})

Étape 1.2 : Créer l'idée

chorus_pm_create_idea({
  projectUuid: "<uuid-projet>",
  title: "<titre concis dérivé du prompt>",
  content: "<prompt utilisateur complet tel quel>"
})

Puis revendiquez-la :

chorus_claim_idea({ ideaUuid: "<uuid-idée>" })

É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. Il n'y a pas de primitive AskUserQuestion sur OpenClaw, et yolo ne demande délibérément pas à l'utilisateur ; il s'auto-répond pour préserver une piste d'audit sans interrompre l'exécution.

L'auto-élaboration est toujours une boucle. Si répondre à vos propres questions révèle une nouvelle question, contradiction ou lacune, bouclez vers chorus_pm_start_elaboration pour un autre tour auto-répondu avant de résoudre — ne forcez pas une résolution sur une ambiguïté non résolue. Il n'y a pas de porte humaine dans YOLO, donc la boucle se termine sur votre jugement que rien de matériel n'est laissé ouvert (plafond de 10 tours). Les étapes 1–2 sont un tour ; répétez-les au besoin, puis résolvez une fois à l'étape 3.

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

   chorus_pm_start_elaboration({
     ideaUuid: "<uuid-idée>",
     depth: "standard",
     questions: [
       {
         id: "q1",
         text: "<question sur la portée, l'architecture, etc.>",
         category: "functional",
         options: [
           { id: "a", label: "<option A>" },
           { id: "b", label: "<option B>" }
         ]
       }
       // ... 5-8 questions couvrant les aspects fonctionnels, techniques, de portée
     ]
   })

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

   chorus_answer_elaboration({
     ideaUuid: "<uuid-idée>",
     roundUuid: "<uuid-tour>",
     answers: [
       { questionId: "q1", selectedOptionId: "a", customText: "Justification : ..." },
       // ...
     ]
   })

3. Résoudre — en mode YOLO, l'agent résout l'élaboration de façon autonome, sans porte de confirmation humaine (l'exigence de confirmation humaine qui s'applique au flux interactif /idea est explicitement levée sous l'automatisation /yolo) :

   chorus_pm_validate_elaboration({
     ideaUuid: "<uuid-idée>"
   })

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

Étape 1.4 : Créer la proposition

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

   Note OpenClaw : il n'y a pas de hook Claude Code SessionStart pour précalculer CHORUS_OPENSPEC_ACTIVE. Vous devez exécuter les trois vérifications vous-même, en ligne, 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 spec (sous-étape 2a ci-dessous).
   • Une 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: "<uuid-projet>",
     title: "<nom de fonctionnalité>",
     description: "<résumé>\n\nOpenSpec change slug: <slug>",   // mode OpenSpec
     // description: "<résumé>",                                 // mode libre
     inputType: "idea",
     inputUuids: ["<uuid-idée>"]
   })

   Puis bifurquez :

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

   • Choisissez $SLUG, exécutez openspec new change "$SLUG" (§3.1–§3.2).
   • Rédigez proposal.md, design.md, et un specs/<capability>/spec.md par capacité localement sur disque (§3.3). Seulement les Exigences ADDED ; par défaut à Markdown libre si MODIFIED/REMOVED est nécessaire.
   • Définissez les assistants json_encode_file, chorus_check_response (§3.4, §6).
   • Reflétez chaque fichier local via chorus-api.sh mcp-tool chorus_pm_add_document_draft "$PAYLOAD" (§3.6) — un appel par fichier, avec le type de document de openspec-aware §5.

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

   Puis continuez à l'étape 3 (brouillons de tâches).

   2b. Mode libre (une vérification échoue). Ajoutez un brouillon de document de conception technique directement via MCP, contenu rédigé en ligne :

   chorus_pm_add_document_draft({
     proposalUuid: "<uuid-proposition>",
     type: "tech_design",
     title: "Tech Design: <fonctionnalité>",
     content: "<markdown tech design couvrant architecture, modèle de données, API, contrats de module>"
   })

3. Ajouter les brouillons de tâches progressivement (utilisez l'draftUuid retourné pour le chaînage des dépendances). acceptanceCriteriaItems est requis sur chaque brouillon — au moins un critère non vide, sinon l'appel est rejeté :

   # Première tâche
   result1 = chorus_pm_add_task_draft({
     proposalUuid: "<uuid-proposition>",
     title: "<nom du module>",
     description: "<ce à construire, référençant la conception technique>",
     priority: "high",
     storyPoints: 3,
     acceptanceCriteriaItems: [
       { description: "<critère testable>", required: true },
       // ...
     ]
   })
   
   # Deuxième tâche, dépend de la première
   chorus_pm_add_task_draft({
     proposalUuid: "<uuid-proposition>",
     title: "<module dépendant>",
     description: "...",
     priority: "medium",
     storyPoints: 2,
     acceptanceCriteriaItems: [...],
     dependsOnDraftUuids: ["<result1.draftUuid>"]
   })

4. Valider :

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

   Corrigez les erreurs, puis procédez.

5. Soumettre :

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

   Procédez immédiatement à la Phase 2 et exécutez l'examinateur de proposition en ligne — OpenClaw n'a pas de hook PostToolUse pour vous le rappeler.

Phase 2 : Boucle d'examen de la proposition

Différence OpenClaw : il n'y a pas de hook PostToolUse injectant un rappel « générer l'examinateur ». Exécutez l'examinateur en ligne, juste après chorus_pm_submit_proposal.

Obtenir un VERDICT indépendant sur la proposition :

• Préféré — générer un sous-agent examinateur. Utilisez l'outil OpenClaw sessions_spawn pour générer un sous-agent dont la task lui demande d'invoquer la skill /proposal-reviewer (fournie avec ce plugin) contre la proposition, puis attendez-le (interrogez l'outil subagents, ou utilisez sessions_yield — ne détachez PAS ; vous avez besoin du VERDICT avant de procéder). Le sous-agent hérite des skills du plugin, donc /proposal-reviewer est disponible pour lui ; cette skill est en lecture seule et se termine par un commentaire VERDICT: sur la proposition. Exemple de prompt de tâche :

  Exécutez la skill /proposal-reviewer pour examiner proposalUuid <uuid>. Ceci est le tour d'examen <N>. Lisez la proposition, ses documents, l'idée et l'élaboration ; classifiez les résultats comme BLOCKER/NOTE ; postez votre commentaire VERDICT sur la proposition quand c'est fait.

• Secours — l'examiner vous-même. Si sessions_spawn n'est pas disponible (par ex. génération désactivée par politique), faites vous-même l'examen comme une passe ciblée en lecture seule en suivant la procédure de la skill /proposal-reviewer (lire proposition + commentaires + idée + élaboration ; vérifier la complétude des docs, la granularité des tâches, la couverture AC↔exigence, le DAG, et les points de contrôle d'intégration ; classer BLOCKER/NOTE) et enregistrez le résultat via chorus_add_comment se terminant par une ligne VERDICT:. Ne modifiez pas les brouillons pendant la passe d'examen.

Puis :

1. Lire le VERDICT de l'examinateur :

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

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

2. Agir sur le VERDICT :

   • PASS ou PASS WITH NOTES --

     chorus_admin_approve_proposal({
       proposalUuid: "<uuid-proposition>",
       reviewNote: "PASS de l'examinateur. <résumé bref des notes le cas échéant>"
     })

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

   • FAIL -- Lisez les BLOCKERs du commentaire de l'examinateur. Puis :

     chorus_pm_reject_proposal({
       proposalUuid: "<uuid-proposition>",
       reviewNote: "FAIL de l'examinateur. Correction des BLOCKERs : <liste>"
     })

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

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

     Après resoumission, exécutez l'examinateur en ligne à nouveau pour le tour 2 (même que ci-dessus).

3. Nombre de tours maximum : Bouclez jusqu'à maxProposalReviewRounds (de la config du plugin, par défaut 3). Si épuisé :

   STOP: "Examen de la proposition échoué après {maxRounds} tours.
          BLOCKERs restants : <liste>. Examen humain nécessaire.
          UUID de la proposition : <uuid>"

4. Pas de nouveau commentaire VERDICT après le retour de l'examinateur généré ? Il a épuisé son budget de tours. Regénérez-le UNE FOIS avec un indice de budget concis : "Restez dans le budget de tours. Ignorez la vérification source approfondie. Récupérez seulement proposition + commentaires + idée, parcourez pour les BLOCKERs évidents, et postez votre VERDICT dans les premiers 10 tours." Si toujours pas de VERDICT, passez à l'examen manuel et postez vous-même le VERDICT — le pipeline ne peut pas boucler indéfiniment sur un examinateur silencieux.

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

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

Différence OpenClaw : OpenClaw n'a pas de primitive Agent Teams / TeamCreate. Exécutez les vagues séquentiellement comme l'agent principal : bouclez chorus_get_unblocked_tasks, implémentez vous-même chaque tâche prête, vérifiez-la, puis bouclez à nouveau pour la vague suivante. N'appelez PAS TeamCreate — il n'existe pas sur OpenClaw. (Sous le plugin Claude Code, chaque vague peut être distribuée en parallèle via TeamCreate ; c'est une optimisation réservée à Claude Code qui se réduit à la boucle séquentielle ici.)

vague = 1

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

  if pas de tâches déverrouillées et toutes les tâches faites/fermées:
    break  # Tout est complet

  if pas de tâches déverrouillées et certaines tâches pas faites:
    # Bloqué -- les tâches ont échoué l'examen et ne peuvent pas procéder
    break avec rapport d'escalade

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

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

    chorus_report_work({ taskUuid: tâche.uuid, report: "...", status: "to_verify" })
    chorus_report_criteria_self_check({ taskUuid: tâche.uuid, criteria: [...] })
    chorus_submit_for_verify({ taskUuid: tâche.uuid, summary: "..." })

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

  vague += 1

Distribution optionnelle de sous-agent : si votre hôte OpenClaw supporte des sous-agents workers génériques (pas Agent Teams), vous pouvez remettre 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 « Distribution optionnelle de sous-agent ». L'agent principal possède toujours l'examen + vérification. Cela ne change pas la structure séquentielle, vague par 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 :

pour la tâche juste soumise :
  # 1. Vérifier le statut de la tâche
  tâche = chorus_get_task({ taskUuid: "<uuid-tâche>" })

  if tâche.status != "to_verify":
    # l'implémentation peut avoir échoué ; gérez ou ignorez
    continue

  # 2. Exécutez le task-reviewer EN LIGNE (pas de hook sur OpenClaw) :
  #    - Préféré : utilisez l'outil sessions_spawn pour générer un sous-agent dont la tâche est
  #      « Exécutez la skill /task-reviewer pour vérifier taskUuid <uuid> (tour <N>) ; postez votre
  #      commentaire VERDICT sur la tâche quand c'est fait. » Attendez-le (interrogez l'outil
  #      subagents / utilisez sessions_yield — NE détachez PAS ; vous avez besoin du VERDICT). Le
  #      sous-agent hérite des skills du plugin, donc /task-reviewer est disponible pour lui.
  #    - Secours (sessions_spawn indisponible) : vérifiez-la vous-même comme une passe ciblée en
  #      lecture seule en suivant la procédure de /task-reviewer (lire tâche + proposition + docs +
  #      code, exécuter les tests en lecture seule, classer BLOCKER/NOTE) et postez le VERDICT via
  #      chorus_add_comment.

  # 3. Lire le VERDICT du task-reviewer
  commentaires = chorus_get_comments({ targetType: "task", targetUuid: "<uuid-tâche>" })
  # Trouvez le commentaire le plus récent contenant "VERDICT:"

  # 4. Agir sur le VERDICT — trois résultats possibles :
  if VERDICT est "PASS":
    chorus_mark_acceptance_criteria({
      taskUuid: "<uuid-tâche>",
      criteria: [
        { uuid: "<uuid-ac>", status: "passed", evidence: "<de l'examinateur>" },
        // ...
      ]
    })
    chorus_admin_verify_task({ taskUuid: "<uuid-tâche>" })
    # La tâche est maintenant « done » -- déverrouille les dépendants pour la vague suivante

  if VERDICT est "PASS WITH NOTES":
    chorus_mark_acceptance_criteria({ ... })
    chorus_admin_verify_task({ taskUuid: "<uuid-tâche>" })

  if VERDICT est "FAIL":
    # BLOCKERs trouvés. Ne VÉRIFIEZ PAS. Réouvrez pour refonte.
    chorus_admin_reopen_task({ taskUuid: "<uuid-tâche>" })
    # Corrigez les BLOCKERs dans une passe ultérieure (la tâche retourne à in_progress/open)

Après vérification des tâches de la vague, retournez à la boucle de la Phase 3 pour récupérer les tâches nouvellement déverrouillées. Rappelez-vous : seul done (pas to_verify) déverrouille les dépendants.

Tours maximum par tâche : Suivi par maxTaskReviewRounds de la config du plugin (par défaut 3). Si une tâche a été rouverte maxRounds fois, ignorez-la et signalez-la pour escalade manuelle :

ESCALATE: "La tâche '{titre}' a échoué l'examen après {maxRounds} tours.
           Derniers BLOCKERs : <liste>. Intervention manuelle nécessaire.
           UUID de la tâche : <uuid>"

Continuez avec les tâches restantes -- ne halassez pas tout le pipeline pour une tâche bloquée.

Pas de nouveau commentaire VERDICT après le retour du task-reviewer généré ? Il a épuisé son budget de tours. Regénérez-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 centraux, et postez votre VERDICT dans les premiers 12 tours." Si toujours pas de VERDICT, passez à l'examen manuel et postez vous-même le VERDICT — ne bouclez pas indéfiniment.

Phase 4.5 : Porte d'examen de code (obligatoire avant livraison)

Une fois que chaque tâche de la proposition de l'idée est vérifiée (done) — Phase 3 ne trouve pas d'autres tâches déverrouillées et aucune n'est non-terminale — exécutez la porte d'examen de code finale avant la livraison avant le rapport d'accomplissement de la Phase 5b. Elle examine la totalité du changement de code agrégé de l'idée sur toutes les tâches (pas une seule tâche) et poste son verdict sur l'idée. En ligne (pas de hook sur OpenClaw), même mécanisme que la Phase 4 :

• Préféré — générer un sous-agent examinateur. Utilisez sessions_spawn pour générer un sous-agent dont la task lui dit d'invoquer la skill /code-reviewer contre l'idée, puis attendez-le (interrogez subagents / sessions_yield — ne détachez PAS). Exemple de prompt de tâche : Exécutez la skill /code-reviewer pour examiner le code agrégé pour ideaUuid <uuid> (tour <N>) ; postez votre commentaire VERDICT sur l'idée quand c'est fait.
• Secours — l'examiner vous-même. Si sessions_spawn n'est pas disponible, faites l'examen comme une passe ciblée en lecture seule en suivant la procédure de /code-reviewer (lire l'idée, ses propositions approuvées + documents + tâches ; déduire le diff agrégé des rapports de tâche + git log/diff ; examiner l'intégration inter-tâches, l'architecture, la sécurité, la régression, la couverture au niveau de la fonctionnalité ; exécuter la génération/test du projet) et postez vous-même le commentaire VERDICT: sur l'idée.

Agissez sur le VERDICT :

• PASS / PASS WITH NOTES — la fonctionnalité est cleared pour livraison. Procédez à la Phase 5 / 5b.
• FAIL — NE LIVREZ PAS. Lisez les BLOCKERs, puis corrigez-les via le workflow quick-dev (/quick-dev) : appelez chorus_create_tasks avec proposalUuid défini à la proposition approuvée actuelle pour que les tâches de correction s'y attachent — ne réouvrez PAS les tâches déjà vérifiées. Pilotez-les via la Phase 3 → Phase 4, puis réexécutez la porte pour le tour suivant. Boucle limitée par maxCodeReviewRounds (par défaut 3 ; 0 = illimité).

ESCALATE: "L'idée '{titre}' a échoué l'examen de code après {maxCodeReviewRounds} tours.
           Derniers BLOCKERs : <liste>. Intervention manuelle nécessaire. UUID de l'idée : <uuid>"

Pas de commentaire VERDICT après le retour du code-reviewer ? Il a épuisé son budget de tours (plus grand que celui du task-reviewer parce qu'il examine toute la fonctionnalité). Regénérez UNE FOIS avec un indice de budget concis ; si toujours silencieux, passez à une passe manuelle en lecture seule et postez vous-même le VERDICT.

La porte est comportementale comme les deux autres examinateurs : son verdict est consultatif et ne change pas le statut stocké de l'Idée ; l'orchestrateur l'honore. Elle s'exécute avant le rapport d'accomplissement pour que le rapport ne soit jamais écrit pendant qu'un FAIL est en attente.

Phase 5 : Rapport

Après que toutes les vagues se terminent, produisez un résumé markdown :

## /yolo Terminé

**Projet :** <nom-projet> (<uuid-projet>)
**Proposition :** <titre-proposition> (<uuid-proposition>)
**Idée :** <titre-idée> (<uuid-idée>)

### Tâches
| Tâche | Statut | Tours d'examen |
|-------|--------|----------------|
| <titre> | done | 1 |
| <titre> | done | 2 |
| <titre> | ESCALATED | 3 (max) |

### Résumé
- Tâches totales : N
- Complétées : X / N
- Escaladées : Y (besoin d'examen humain)
- Vagues exécutées : W

Phase 5b : Rapport d'accomplissement de l'idée (obligatoire)

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

Ordre : écrivez le rapport d'accomplissement seulement après que la porte d'examen de code de la Phase 4.5 retourne PASS / PASS WITH NOTES — jamais pendant qu'un FAIL d'examen de code 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 également le flux d'archivage. OpenClaw n'a pas de hook PostToolUse pour vous le rappeler — après vérification de la tâche finale, exécutez vous-même openspec-aware §3.9 (openspec archive <slug> --yes, puis refletez 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 proposal-reviewer est votre porte de qualité -- s'il continue de FAILer, le prompt peut être trop vague
• Observez le nombre de vagues -- si les tâches continuent d'être rouverte, envisagez d'arrêter et d'examiner le feedback manuellement
• Toute la piste d'audit est préservée : Q&A d'élaboration, VERDICTs de l'examinateur, rapports de travail. Vérifiez l'interface Chorus pour l'historique complet
• Pour les tâches petites/simples, envisagez /quick-dev à la place -- il ignore les frais généraux Idée->Proposition
• Les sous-agents (si vous en distribuez) partagent votre clé API ; assurez-vous qu'elle a les permissions listées dans Prérequis avant de démarrer

Suivant

• Pour examiner manuellement les propositions : /review
• Pour développer manuellement les tâches : /develop
• Pour créer des tâches autonomes rapides : /quick-dev
• Pour un aperçu de la plateforme : /chorus