Compétence Yolo

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

Vue d'ensemble

/yolo automatise le workflow AI-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 le projet, l'idée, auto-élaboration, proposition avec docs et tâches
2. Examen de la proposition -- boucle adversariale avec l'examinateur de proposition
3. Exécution -- distribution parallèle des tâches par ondes avec Agent Team
4. Vérification -- boucle adversariale avec l'examinateur de tâches + vérification admin 4.5. Portail d'examen de code -- l'examinateur de code revoit le changement agrégé de l'Idée avant le déploiement (ÉCHEC → ajouter tâches de correction → relancer)
5. Rapport -- résumé d'achèvement

/yolo <prompt>
       |
       v
  Projet + Idée + Élaboration + Proposition
       |
       v
  Examinateur de proposition (auto, jusqu'à maxProposalReviewRounds)
       |
       v
  Approbation Admin --> Les tâches se matérialisent
       |
       v
  Exécution par ondes avec Agent Team
       |  (agent dev + examinateur de tâche par tâche)
       v
  Vérification Admin de chaque onde --> déverrouiller la suivante
       |
       v
  Portail d'examen de code (auto, jusqu'à CHORUS_MAX_CODE_REVIEW_ROUNDS; défaut 3, 0 = illimité)
       |  PASS --> déployer   |   FAIL --> ajouter tâches de correction --> relancer
       v
  Terminé. Résumé du rapport.

Échappatoire : Ctrl+C à 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 a besoin de droits en écriture + 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 au lieu d'en créer un nouveau

Workflow

Phase 1 : Planification

Étape 1.1 : Résoudre le projet

Analyser les arguments pour --project <uuid>.

Si --project est fourni :

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

Vérifier qu'il existe et procéder.

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

# 1. Chercher les 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()

Examiner les résultats. Si un projet correspond clairement à l'intention de l'utilisateur (même sujet, actif, périmètre pertinent), l'utiliser. Si aucun projet approprié n'existe, en créer un :

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

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

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

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 -- pas d'appels AskUserQuestion. Cela préserve une piste d'audit sans interrompre l'utilisateur.

L'auto-élaboration est toujours une boucle. Si répondre à vos propres questions révèle une nouvelle question, contradiction ou lacune, revenir à chorus_pm_start_elaboration pour un autre round auto-répondu avant de résoudre -- ne pas forcer une résolution sur une ambiguïté non résolue. Il n'y a pas de portail humain dans YOLO, donc la boucle se termine selon votre jugement qu'il n'y a rien de matériel d'ouvert (limite de round 10). Les étapes 1-2 forment un round ; les répéter au besoin, puis résoudre 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 sur le périmètre, l'architecture, etc.>",
         category: "functional",
         options: [
           { id: "a", label: "<option A>" },
           { id: "b", label: "<option B>" }
         ]
       }
       // ... 5-8 questions couvrant les aspects fonctionnels, techniques et de périmètre
     ]
   })

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

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

3. Résoudre -- en mode YOLO l'agent résout l'élaboration de manière autonome, sans portail de confirmation humaine (l'exigence de confirmation humaine qui s'applique au flow /idea interactif est explicitement levée sous l'automatisation /yolo) :

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

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

Étape 1.4 : Créer la proposition

1. Détecter le mode OpenSpec. Charger la compétence openspec-aware à skills/openspec-aware/SKILL.md et exécuter son contrat de détection §1. Le résultat détermine comment le reste de cette étape crée les documents :

   • CHORUS_OPENSPEC_ACTIVE=1 → branche pilotée par spec (sous-étape 2a ci-dessous).
   • CHORUS_OPENSPEC_ACTIVE=0 → branche libre (sous-étape 2b ci-dessous).

   Ceci est obligatoire -- yolo s'exécute sans surveillance, donc silencieusement choisir le mauvais mode est exactement le scénario d'échec que le contrat de détection existe pour prévenir.

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

   chorus_pm_create_proposal({
     projectUuid: "<project-uuid>",
     title: "<nom de la fonctionnalité>",
     description: "<résumé>\n\nOpenSpec change slug: <slug>",   // mode OpenSpec
     // description: "<résumé>",                                 // mode libre
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   })

   Puis se brancher :

   2a. Mode OpenSpec (CHORUS_OPENSPEC_ACTIVE=1). Suivre openspec-aware §3 de bout en bout :

   • Choisir $SLUG, exécuter openspec new change "$SLUG" (§3.1–§3.2).
   • Créer proposal.md, design.md, et un specs/<capability>/spec.md par capacité localement sur disque (§3.3). AJOUTÉ uniquement les exigences ; par-spec revenir à Markdown libre si MODIFIÉ/SUPPRIMÉ est nécessaire.
   • Définir les assistants $CHORUS_BIN, json_encode_file, chorus_check_response (§3.4, §6).
   • Refléter chaque fichier local via "$CHORUS_BIN" 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é à la main dans cette branche. Retaper le corps markdown gaspille 20k+ tokens par proposition et casse l'égalité d'octets avec les fichiers locaux. Voir openspec-aware §2 Règle 1.

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

   2b. Mode libre (CHORUS_OPENSPEC_ACTIVE=0). Ajouter un brouillon de document de conception technique directement via MCP, contenu créé en ligne :

   chorus_pm_add_document_draft({
     proposalUuid: "<proposal-uuid>",
     type: "tech_design",
     title: "Tech Design: <fonctionnalité>",
     content: "<markdown de conception technique couvrant l'architecture, le modèle de données, l'API, les contrats de module>"
   })

3. Ajouter les brouillons de tâches progressivement (utiliser le draftUuid retourné pour chaîner les dépendances). acceptanceCriteriaItems est obligatoire sur chaque brouillon -- au moins un critère non vierge, sinon l'appel est rejeté :

   # Première tâche
   result1 = chorus_pm_add_task_draft({
     proposalUuid: "<proposal-uuid>",
     title: "<nom du module>",
     description: "<ce qu'il faut construire, en 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: "<proposal-uuid>",
     title: "<module dépendant>",
     description: "...",
     priority: "medium",
     storyPoints: 2,
     acceptanceCriteriaItems: [...],
     dependsOnDraftUuids: ["<result1.draftUuid>"]
   })

4. Valider :

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

   Corriger les erreurs, puis procéder.

5. Soumettre :

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

   Après cet appel, l'extension vous incite à lancer chorus-proposal-reviewer. Vous DEVEZ le lancer vous-même via l'outil subagent bloquant (il attend le VERDICT) -- ce n'est PAS lancé automatiquement.

Phase 2 : Boucle d'examen de proposition

Après chorus_pm_submit_proposal, l'extension vous incite à lancer chorus-proposal-reviewer. Vous DEVEZ le lancer manuellement comme sous-agent en lecture seule via l'outil subagent bloquant (il attend le VERDICT). Attendez qu'il se termine, puis :

1. Lire le VERDICT de l'examinateur :

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

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

2. Agir sur le VERDICT :

   • PASS ou PASS WITH NOTES --

     chorus_admin_approve_proposal({
       proposalUuid: "<proposal-uuid>",
       reviewNote: "PASS de l'examinateur. <bref résumé des notes si nécessaire>"
     })

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

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

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

     Réviser les brouillons (chorus_pm_update_document_draft, chorus_pm_update_task_draft) pour corriger chaque BLOCKER, puis soumettre à nouveau :

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

     Après resoumission, l'extension vous incite à nouveau -- lancez l'examinateur vous-même pour le Round 2.

3. Nombre max de rounds : Boucler jusqu'à maxProposalReviewRounds (depuis la config du plugin, défaut 3). Si épuisé :

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

4. Aucun nouveau commentaire VERDICT après le retour de l'examinateur ? L'examinateur a épuisé son budget de tours. Le relancer UNE FOIS avec un indice de budget concis : "Rester dans le budget de tours. Passer la vérification profonde de source. Récupérer la proposition + commentaires + idée seulement, examiner rapidement les BLOCKERs évidents, et poster votre VERDICT dans les 10 premiers tours." Si la deuxième tentative ne produit toujours pas de VERDICT, traiter la proposition comme PASS WITH NOTES et procéder -- le pipeline ne peut pas boucler éternellement sur un examinateur silencieux.

Phase 3 : Exécution des tâches (par ondes)

Après l'approbation de la proposition, les tâches existent en statut open. Les exécuter en ondes ordonnées par dépendances en utilisant des sous-agents. Si le lancement échoue, revenir à l'exécution par l'agent principal.

Principal : Agent Team (parallèle)

wave = 1

loop:
  # 1. Trouver les tâches prêtes
  unblocked = chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })

  if no unblocked tasks and all tasks done:
    break  # Tous terminés

  if no unblocked tasks and some tasks not done:
    # Bloqué -- les tâches ont échoué l'examen et ne peuvent pas procéder
    break with escalation report

  # 2. Lancer un sous-agent pour chaque tâche déverrouillée (async)
  #    L'extension chorus-pi injecte automatiquement la session UUID + workflow
  #    dans la tâche de chaque worker au moment de l'appel tool_call.
  for each task in unblocked:
    subagent_spawn({
      agent: "worker",
      task: "Votre UUID de tâche Chorus : {task.uuid}\nUUID du projet : {project-uuid}\n\nMettez en œuvre la tâche selon sa description et ses critères d'acceptation. Lisez la tâche, la proposition et les documents du projet pour le contexte."
    })
    # conserver l'agentId retourné (sa_<uuid>) pour fermer le worker plus tard

  # 3. Attendre que tous les sous-agents se terminent
  #    Chaque sous-agent suit le workflow /skill:develop :
  #    claim -> in_progress -> develop -> report -> self-check AC -> submit_for_verify
  #    l'extension vous incite à lancer chorus-task-reviewer après submit_for_verify
  #    (utiliser l'outil `subagent` bloquant pour qu'il attende le VERDICT)

  # 4. Procéder à la Phase 4 (vérification) pour cette onde
  wave += 1

Ce que le prompt du sous-agent doit contenir :

• UUID(s) de la tâche
• UUID du projet
• PAS d'UUID de session, PAS de boilerplate de workflow -- l'extension injecte automatiquement via mutation tool_call

Secours : Agent principal (séquentiel)

Si subagent_spawn échoue (p. ex. pi-subagents non installé, permission refusée, ou les sous-agents s'écrasent à répétition), revenir à l'exécution séquentielle des tâches comme agent principal :

for each task in unblocked:
  # Suivre le workflow /develop directement comme agent principal
  chorus_claim_task({ taskUuid: "<task-uuid>" })
  chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })

  # ... implémenter la tâche : lire le contexte, écrire du code, exécuter les tests ...

  chorus_report_work({ taskUuid: "<task-uuid>", report: "..." })
  chorus_report_criteria_self_check({ taskUuid: "<task-uuid>", criteria: [...] })
  chorus_submit_for_verify({ taskUuid: "<task-uuid>", summary: "..." })

  # l'extension injecte le contexte -- vous devez lancer task-reviewer vous-même
  # Procéder à la Phase 4 de vérification pour cette tâche avant de passer à la suivante

Le secours est plus lent (séquentiel, pas parallèle) mais complète tout de même le pipeline. L'extension injecte les instructions de l'examinateur de la même manière dans les deux modes -- vous devez toujours lancer l'examinateur manuellement.

Phase 4 : Vérification

Après que les sous-agents de chaque onde se terminent, vérifier leurs tâches :

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

  if task.status != "to_verify":
    # Le sous-agent peut avoir échoué ; passer ou gérer
    continue

  # 2. Lancer chorus-task-reviewer (l'extension vous incite ; vous devez le lancer vous-même)
  #    Utiliser l'outil `subagent` bloquant (il attend le VERDICT avant de retourner)
  subagent({ agent: "chorus-task-reviewer", task: "Vérifier la tâche <task-uuid>..." })

  # 3. Lire le VERDICT de task-reviewer
  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":
    # Tous les AC vérifiés, aucun problème. Marquer AC et vérifier.
    chorus_mark_acceptance_criteria({
      taskUuid: "<task-uuid>",
      criteria: [
        { uuid: "<ac-uuid>", status: "passed", evidence: "<de l'examinateur>" },
        // ...
      ]
    })
    chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
    # La tâche est maintenant "done" -- déverrouille les dépendants

  if VERDICT is "PASS WITH NOTES":
    # Tous les AC vérifiés, notes mineures non bloquantes. Toujours marquer AC et vérifier.
    chorus_mark_acceptance_criteria({ ... })
    chorus_admin_verify_task({ taskUuid: "<task-uuid>" })

  if VERDICT is "FAIL":
    # BLOCKERs trouvés. NE PAS vérifier. Rouvrir pour retouche.
    chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
    # La tâche revient à "open", sera reprise dans l'onde suivante

Après vérification de toutes les tâches de l'onde, revenir à la Phase 3 pour vérifier les tâches nouvellement déverrouillées.

Nombre max de rounds par tâche : Suivi par maxTaskReviewRounds de la config du plugin (défaut 3). Si une tâche a été rouverte maxRounds fois, la passer et la signaler pour escalade humaine :

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

Continuer avec les tâches restantes -- ne pas arrêter tout le pipeline pour une tâche bloquée.

Aucun nouveau commentaire VERDICT après le retour de task-reviewer ? L'examinateur a épuisé son budget de tours. Le relancer UNE FOIS avec un indice de budget concis : "Rester dans le budget de tours. Passer la vérification profonde. Récupérer tâche/proposition/commentaires, exécuter seulement les tests principaux, et poster votre VERDICT dans les 12 premiers tours." Si la deuxième tentative ne produit toujours pas de VERDICT, traiter comme PASS WITH NOTES et procéder -- ne pas boucler indéfiniment.

Phase 4.5 : Portail d'examen de code (obligatoire avant déploiement)

Une fois que toutes les tâches de la proposition de l'Idée sont vérifiées (done) -- c.à.d. la Phase 3 ne trouve plus de tâches déverrouillées et toutes sont en état terminal -- exécuter le portail d'examen de code final au moment du déploiement avant de déclarer l'Idée terminée et avant le rapport d'achèvement de la Phase 5b. Après que la dernière tâche soit vérifiée, l'extension vous incite à lancer l'examinateur de code ; vous DEVEZ le lancer vous-même via l'outil subagent bloquant (il attend le VERDICT).

# Lancer l'examinateur de code pour l'IDÉE (pas une tâche). Déterminer le numéro
# de round en lisant les commentaires VERDICT précédents d'examen de code sur l'idée.
subagent({ agent: "chorus-code-reviewer",
           task: "Vérifier le code agrégé pour l'idée <idea-uuid>. Round : N." })

# Lire son VERDICT sur l'idée
comments = chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" })
# Trouver le commentaire le plus récent contenant "VERDICT:"

Agir sur le VERDICT :

• PASS / PASS WITH NOTES -- la fonctionnalité est autorisée à être déployée. Procéder à la Phase 5 / 5b.
• FAIL -- NE PAS déployer. Lire les BLOCKERs, puis les corriger via le workflow quick-dev (/quick-dev) : appeler chorus_create_tasks avec proposalUuid défini à la proposition approuvée actuelle pour que les tâches de correction s'y rattachent -- NE PAS rouvrir les tâches déjà vérifiées. Conduire les tâches de correction à travers la Phase 3 (exécuter) → Phase 4 (vérifier), puis relancer l'examinateur de code pour le round suivant. Boucle bornée par CHORUS_MAX_CODE_REVIEW_ROUNDS (env, défaut 3 ; 0 = illimité) ; la Référence Rapide injectée indique la valeur actuelle.

# Escalade nombre max de rounds
ESCALATE: "Idée '{titre}' a échoué l'examen de code après {CHORUS_MAX_CODE_REVIEW_ROUNDS} rounds.
           Derniers BLOCKERs : <liste>. Intervention manuelle nécessaire. UUID de l'idée : <uuid>"

Aucun nouveau commentaire VERDICT après le retour de l'examinateur de code ? L'examinateur a épuisé son budget de tours (l'examinateur de code s'exécute avec un budget plus grand que l'examinateur de tâche car il revoit la fonctionnalité complète). Le relancer UNE FOIS avec un indice de budget concis, puis s'il reste silencieux traiter comme PASS WITH NOTES et procéder -- ne pas boucler éternellement sur un examinateur silencieux.

Le portail d'examen de code est comportemental, cohérent avec les examinateurs de proposition/tâche : son verdict est consultatif et ne change pas le statut stocké de l'Idée. L'orchestrateur /yolo l'honore -- PASS pour déployer, FAIL pour boucler. Il s'exécute avant le rapport d'achèvement pour que le rapport ne soit jamais écrit pour une fonctionnalité avec un FAIL en attente.

Phase 5 : Rapport

Après que toutes les ondes se terminent, générer un résumé markdown :

## /yolo Terminé

**Projet :** <nom du projet> (<project-uuid>)
**Proposition :** <titre de la proposition> (<proposal-uuid>)
**Idée :** <titre de l'idée> (<idea-uuid>)

### Tâches
| Tâche | Statut | Rounds 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 de révision humaine)
- Ondes exécutées : W

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

Un run /yolo réussi termine toujours l'Idée -- appeler 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 ; le suivre. Afficher le documentUuid retourné dans le résumé de la Phase 5. Sauter est une violation de protocole.

Ordre : le rapport d'achèvement est écrit seulement après que le portail d'examen de code de la Phase 4.5 retourne PASS / PASS WITH NOTES. Ne jamais l'écrire alors qu'un FAIL d'examen de code est en attente -- le rapport est un résumé au moment du déploiement, et le portail est ce qui autorise la fonctionnalité à être déployée.

Gestion des erreurs

Conseils

• Garder le prompt initial détaillé -- plus vous fournissez de contexte, mieux la qualité de la proposition auto-générée
• L'examinateur de proposition est votre portail qualité -- s'il continue de FAILer, le prompt peut être trop vague
• Surveiller le nombre d'ondes -- si les tâches continuent d'être rouverte, envisager Ctrl+C et examiner manuellement le retour d'information
• Toute la piste d'audit est préservée : Q&A d'élaboration, VERDICTs des examinateurs, rapports de travail. Vérifier l'interface Chorus pour l'historique complet
• Pour des tâches petites/simples, envisager /quick-dev à la place -- cela ignore les frais généraux Idée->Proposition
• Les sous-agents partagent votre clé API ; assurer qu'elle a les permissions listées dans Prérequis avant de commencer

Suivant

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