Skill Yolo

Pipeline IA complètement 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 complet 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 le projet, l'idée, auto-élaboration, proposition avec docs et tâches
2. Examen de la proposition -- boucle adversariale proposal-reviewer
3. Exécution -- dispatch parallèle des tâches par vagues avec Agent Team
4. Vérification -- boucle adversariale task-reviewer + vérification admin
5. Rapport -- résumé d'achèvement

/yolo <prompt>
       |
       v
  Projet + Idée + Élaboration + Proposition
       |
       v
  Proposal Reviewer (auto, jusqu'à maxProposalReviewRounds)
       |
       v
  Admin Approuve --> Les tâches se matérialisent
       |
       v
  Exécution d'Agent Team par vagues
       |  (agent dev + task-reviewer par tâche)
       v
  Admin Vérifie chaque vague --> déverrouille la suivante
       |
       v
  Terminé. Résumé du rapport.

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

Prérequis

La clé API doit avoir les 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 <uuid-project>

• <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, d'abord chercher un projet existant convenable :

# 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, portée pertinente), l'utiliser. Si aucun projet convenable n'existe, en créer un :

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

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

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

Puis la revendiquer :

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

É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 reste une boucle. Si répondre à vos propres questions révèle une nouvelle question, contradiction ou lacune, revenir à chorus_pm_start_elaboration pour une autre ronde auto-répondue avant de résoudre -- ne forcez pas une résolution sur une ambiguïté non résolue. Il n'y a pas de barrière humaine dans YOLO, donc la boucle se termine sur votre jugement qu'aucune question importante n'est ouverte (plafond 10 rondes). Les étapes 1-2 constituent une ronde ; répéter au besoin, puis résoudre une seule fois à l'étape 3.

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

   chorus_pm_start_elaboration({
     ideaUuid: "<uuid-idea>",
     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 en fonction du prompt) :

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

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

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

   chorus_pm_validate_elaboration exige idea:admin. /yolo exige déjà une clé Admin-preset en Prérequis, donc c'est satisfait. Pour ouvrir une autre ronde 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 le skill openspec-aware à .claude/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 rédige les documents :

   • CHORUS_OPENSPEC_ACTIVE=1 → branche spec-driven (sous-étape 2a ci-dessous).
   • CHORUS_OPENSPEC_ACTIVE=0 → branche free-form (sous-étape 2b ci-dessous).

   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.

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 free-form, omettre cette ligne.

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

   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).
   • Rédiger proposal.md, design.md, et un specs/<capability>/spec.md par capacité localement sur disque (§3.3). Seulement les exigences ADDED ; par spec revenir à Markdown free-form si MODIFIED/REMOVED est nécessaire.
   • Définir les assistants $API, json_encode_file, chorus_check_response (§3.4, §6).
   • Refléter chaque fichier local via "$API" 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é à la main dans cette branche. Re-taper le corps markdown gaspille 20k+ tokens par proposition et casse l'égalité des bytes avec les fichiers locaux. Voir openspec-aware §2 Règle 1.

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

   2b. Mode free-form (CHORUS_OPENSPEC_ACTIVE=0). Ajouter un brouillon de document de conception technique directement via MCP, contenu rédigé en ligne :

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

3. Ajouter les brouillons de tâches incrémentalement (utiliser draftUuid retourné pour le chaînage des dépendances). acceptanceCriteriaItems est requis 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: "<uuid-proposal>",
     title: "<nom du module>",
     description: "<quoi 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: "<uuid-proposal>",
     title: "<module dépendant>",
     description: "...",
     priority: "medium",
     storyPoints: 2,
     acceptanceCriteriaItems: [...],
     dependsOnDraftUuids: ["<result1.draftUuid>"]
   })

4. Valider :

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

   Corriger les erreurs, puis procéder.

5. Soumettre :

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

   Après cet appel, le hook PostToolUse injecte un contexte vous instruisant de lancer chorus:proposal-reviewer. Vous DEVEZ le lancer vous-même en avant-plan (NE PAS définir run_in_background) -- il n'est PAS lancé automatiquement.

Phase 2 : Boucle d'examen de proposition

Après chorus_pm_submit_proposal, le hook PostToolUse injecte un contexte vous instruisant de lancer chorus:proposal-reviewer. Vous DEVEZ le lancer manuellement en tant que sous-agent en lecture seule en avant-plan (NE PAS définir run_in_background). Attendre qu'il se termine, puis :

1. Lire le VERDICT du revieweur :

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

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

2. Agir sur le VERDICT :

   • PASS ou PASS WITH NOTES --

     chorus_admin_approve_proposal({
       proposalUuid: "<uuid-proposal>",
       reviewNote: "PASS du revieweur. <résumé bref des notes si applicable>"
     })

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

   • FAIL -- Lire les BLOCKERs du commentaire du revieweur. Puis :

     chorus_pm_reject_proposal({
       proposalUuid: "<uuid-proposal>",
       reviewNote: "FAIL du revieweur. Correction des BLOCKERs : <liste>"
     })

     Réviser les brouillons (chorus_pm_update_document_draft, chorus_pm_update_task_draft) pour adresser chaque BLOCKER, puis resoummettre :

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

     Après resoumission, le hook injecte le contexte à nouveau -- lancer le revieweur vous-même pour la ronde 2.

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

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

4. Aucun nouveau commentaire VERDICT après le retour du revieweur ? Le revieweur a épuisé son budget maxTurns. Le relancer UNE FOIS avec un indice de budget concis : "Rester dans le budget de tours. Ignorer la vérification approfondie des sources. Récupérer la proposition + commentaires + idée uniquement, scanner 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 indéfiniment sur un revieweur silencieux.

Phase 3 : Exécution de tâches (par vagues)

Après l'approbation de la proposition, les tâches existent en statut open. Les exécuter en vagues ordonnées par dépendances en utilisant Agent Teams. Si la création d'équipe échoue, revenir à l'exécution par l'agent principal.

Principal : Agent Team (parallèle)

wave = 1

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

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

  if pas de tâches déverrouillées et certaines tâches non terminées:
    # Bloqué -- les tâches ont échoué la vérification et ne peuvent pas procéder
    break avec rapport d'escalade

  # 2. Essayer de créer une équipe pour cette vague
  TeamCreate({ team_name: "yolo-wave-{wave}" })

  # 3. Lancer un sous-agent pour chaque tâche déverrouillée
  for chaque tâche in unblocked:
    Agent({
      name: "task-{titre-court}",
      prompt: "Votre UUID de tâche Chorus : {task.uuid}\nUUID du projet : {uuid-project}\n\nImplémenter la tâche selon sa description et ses critères d'acceptation. Lire la tâche, la proposition et les documents du projet pour le contexte."
    })

  # 4. Attendre que tous les sous-agents se terminent
  #    Chaque sous-agent suit le workflow /develop :
  #    revendiquer -> in_progress -> développer -> rapporter -> self-check AC -> submit_for_verify
  #    Hook PostToolUse injecte le contexte -- l'agent principal doit lancer task-reviewer après submit_for_verify

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

Ce que le prompt du sous-agent doit contenir :

• UUID(s) de tâche
• UUID du projet
• PAS de UUID de session, PAS de boilerplate workflow -- le plugin injecte automatiquement tout via le hook SubagentStart

Fallback : Agent principal (séquentiel)

Si TeamCreate échoue (ex. Agent Teams indisponible, permission refusée, ou les sous-agents crashent à répétition), revenir à l'exécution séquentielle des tâches en tant qu'agent principal :

for chaque tâche in unblocked:
  # Suivre directement le workflow /develop en tant qu'agent principal
  chorus_claim_task({ taskUuid: "<uuid-task>" })
  chorus_update_task({ taskUuid: "<uuid-task>", status: "in_progress" })

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

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

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

Le fallback est plus lent (séquentiel, pas parallèle) mais complète quand même le pipeline. Le hook PostToolUse injecte les instructions du revieweur de la même manière dans les deux modes -- vous devez toujours lancer le revieweur manuellement.

Phase 4 : Vérification

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

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

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

  # 2. Lancer task-reviewer en AVANT-PLAN (hook injecte le contexte -- vous devez le lancer vous-même)
  #    NE PAS définir run_in_background -- vous avez besoin du VERDICT avant de procéder
  Agent({ subagent_type: "chorus:task-reviewer", prompt: "Examiner la tâche <uuid-task>..." })

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

  # 4. Agir sur le VERDICT -- trois résultats possibles :
  if VERDICT is "PASS":
    # Tous les AC vérifiés, pas de problèmes. Marquer les AC et vérifier.
    chorus_mark_acceptance_criteria({
      taskUuid: "<uuid-task>",
      criteria: [
        { uuid: "<uuid-ac>", status: "passed", evidence: "<du revieweur>" },
        // ...
      ]
    })
    chorus_admin_verify_task({ taskUuid: "<uuid-task>" })
    # 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. Quand même marquer les AC et vérifier.
    chorus_mark_acceptance_criteria({ ... })
    chorus_admin_verify_task({ taskUuid: "<uuid-task>" })

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

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

Rondes maximales par tâche : Suivies par maxTaskReviewRounds depuis la config du plugin (défaut 3). Si une tâche a été rouverte maxRounds fois, l'ignorer et signaler pour escalade humaine :

ESCALATE: "Tâche '{titre}' échouée après {maxRounds} rondes de vérification. 
           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 du task-reviewer ? Il a épuisé son budget maxTurns. Le relancer UNE FOIS avec un indice de budget concis : "Rester dans le budget de tours. Ignorer la vérification approfondie. Récupérer la tâche/proposition/commentaires, exécuter seulement les tests centraux, 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 5 : Rapport

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

## /yolo Complet

**Projet :** <nom-project> (<uuid-project>)
**Proposition :** <titre-proposition> (<uuid-proposal>)
**Idée :** <titre-idea> (<uuid-idea>)

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

### Résumé
- Total de tâches : N
- Complétées : X / N
- Escaladées : Y (nécessitent examen humain)
- Vagues exécutées : W

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

Une exécution /yolo réussie termine toujours l'Idée -- appeler 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 ; le suivre. Afficher le documentUuid retourné dans le résumé de la Phase 5. L'ignorer est une violation du protocole.

Gestion des erreurs

Conseils

• Garder le prompt initial détaillé -- plus de contexte vous fournissez, mieux la qualité de la proposition auto-générée
• Le proposal-reviewer est votre barrière qualité -- s'il continue à FAILer, le prompt peut être trop vague
• Surveiller le nombre de vagues -- si les tâches continuent à être rouverte, considérer Ctrl+C et examiner manuellement les retours
• Toute la piste d'audit est conservée : Q&A d'élaboration, VERDICTs du revieweur, rapports de travail. Vérifier l'interface utilisateur Chorus pour l'historique complet
• Pour les petites/simples tâches, considérer /quick-dev -- cela ignore la surcharge Idée->Proposition
• Les sous-agents partagent votre clé API ; vérifier qu'elle a les permissions listées en Prérequis avant de démarrer

Suivant

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