Yolo Skill

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

Aperçu

/yolo automatise le workflow complet de Chorus. 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 proposition-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 4.5. Porte de Code-Review -- code-reviewer examine le changement agrégé de l'Idée avant le déploiement (FAIL → ajouter tâches de correction → réexécuter)
5. Rapport -- résumé d'achèvement

/yolo <prompt>
       |
       v
  Project + Idea + Elaboration + Proposal
       |
       v
  Proposal Reviewer (auto, jusqu'à maxProposalReviewRounds)
       |
       v
  Admin Approve --> Tasks matérialisation
       |
       v
  Exécution Agent Team par vagues
       |  (dev agent + task-reviewer par tâche)
       v
  Admin Verify chaque vague --> déverrouiller la suivante
       |
       v
  Code-Review Gateway (auto, jusqu'à CHORUS_MAX_CODE_REVIEW_ROUNDS; défaut 3, 0 = illimité)
       |  PASS --> déployer   |   FAIL --> ajouter tâches de correction --> réexécuter
       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. Reprendre manuellement via /develop ou /review.

Prérequis

La clé API doit avoir 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 <natural language prompt>
/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 de 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 continuer.

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

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

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 existe, en créer un :

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 les questions d'élaboration et y répond lui-même -- pas d'appels AskUserQuestion. Cela préserve une piste d'audit sans interruption de 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 tour auto-répondu avant la résolution -- ne pas forcer une résolution sur une ambiguïté non résolue. Il n'y a pas de porte humaine en YOLO, donc la boucle sort sur votre jugement qu'aucune ambiguïté matérielle n'est ouverte (plafond de rond 10). Les étapes 1–2 constituent un rond ; les répéter au besoin, puis résoudre une fois à l'étape 3.

1. Générer et soumettre les 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) :

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

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

Étape 1.4: Créer une Proposition

1. Détecter le mode OpenSpec. Charger la skill 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 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: "<project-uuid>",
     title: "<feature name>",
     description: "<summary>\n\nOpenSpec change slug: <slug>",   // mode OpenSpec
     // description: "<summary>",                                 // mode free-form
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   })

   Puis 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). ADDED Requirements uniquement ; par défaut per-spec au free-form Markdown si MODIFIED/REMOVED est nécessaire.
   • Définir les helpers $CHORUS_BIN, json_encode_file, chorus_check_response (§3.4, §6).
   • Mirrorer 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 harness MCP avec un champ content dactylographié à la main dans cette branche. Re-dactylographier 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 créé en ligne :

   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 les brouillons de tâches progressivement (utiliser le draftUuid retourné pour chaîner les 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: "<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 les erreurs, puis continuer.

5. Soumettre:

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

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

Phase 2: Boucle d'Examen de Proposition

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

1. Lire le VERDICT du reviewer :

   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 from reviewer. <brief summary of notes if any>"
     })

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

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

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

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

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

     Après resoumission, l'extension vous incite à nouveau -- spawner le reviewer vous-même pour le tour 2.

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

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

4. Aucun nouveau commentaire VERDICT après le retour du reviewer ? Le reviewer a épuisé son budget de tours. Le respawner UNE FOIS avec un conseil 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 la deuxième tentative ne produit toujours pas de VERDICT, traiter la proposition comme PASS WITH NOTES et continuer -- le pipeline ne peut pas boucler indéfiniment sur un reviewer silencieux.

Phase 3: Exécution des 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épendance en utilisant des sous-agents. Si le spawning échoue, revenir à l'exécution par l'agent principal.

Primaire: 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 complets

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

  # 2. Spawner un sous-agent pour chaque tâche déverrouillée (async)
  #    L'extension chorus-pi injecte automatiquement la session UUID + workflow
  #    dans chaque worker à l'heure de l'appel d'outil.
  for each task in unblocked:
    subagent_spawn({
      agent: "worker",
      task: "Your Chorus task UUID: {task.uuid}\nProject UUID: {project-uuid}\n\nImplement the task per its description and acceptance criteria. Read the task, proposal, and project documents for context."
    })
    # 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 à spawner chorus-task-reviewer après submit_for_verify
  #    (utiliser l'outil bloquant `subagent` pour qu'il attende le VERDICT)

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

Ce que le prompt du sous-agent a besoin:

• UUID(s) de Tâche
• UUID de Projet
• AUCUN UUID de session, AUCUN boilerplate de workflow -- l'extension injecte automatiquement via mutation d'appel d'outil

Fallback: Agent Principal (séquentiel)

Si subagent_spawn échoue (par ex., pi-subagents non installé, permission refusée, ou les sous-agents crashent répétitivement), revenir à l'exécution des tâches de manière séquentielle en tant qu'agent principal :

for each task in unblocked:
  # Suivre le workflow /develop directement en tant qu'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 le code, lancer 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 spawner le 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 termine quand même le pipeline. L'extension injecte les instructions du reviewer de la même manière dans les deux modes -- vous devez toujours spawner le reviewer manuellement.

Phase 4: Vérification

Après que les sous-agents de chaque vague 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é ; ignorer ou gérer
    continue

  # 2. Spawner chorus-task-reviewer (l'extension vous incite ; vous devez le spawner vous-même)
  #    Utiliser l'outil `subagent` bloquant (il attend le VERDICT avant de revenir)
  subagent({ agent: "chorus-task-reviewer", task: "Review task <task-uuid>..." })

  # 3. Lire le VERDICT du task-reviewer
  comments = chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
  # 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, aucun problème. Marquer les AC et vérifier.
    chorus_mark_acceptance_criteria({
      taskUuid: "<task-uuid>",
      criteria: [
        { uuid: "<ac-uuid>", status: "passed", evidence: "<from reviewer>" },
        // ...
      ]
    })
    chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
    # Task est maintenant "done" -- déverrouille les dépendants

  if VERDICT is "PASS WITH NOTES":
    # Tous les AC vérifiés, notes mineures sans blocage. Toujours marquer les 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 révision.
    chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
    # Task revient à "open", sera reprise à la vague suivante

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

Max rondes 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: "Task '{title}' failed review after {maxRounds} rounds.
           Last BLOCKERs: <list>. Manual intervention needed.
           Task UUID: <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 de tours. Le respawner UNE FOIS avec un conseil 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 la deuxième tentative ne produit toujours pas de VERDICT, traiter comme PASS WITH NOTES et continuer -- ne pas boucler indéfiniment.

Phase 4.5: Porte de Code-Review (obligatoire pré-déploiement)

Une fois que chaque tâche de la proposition de l'idée est vérifiée (done) -- c'est-à-dire que la Phase 3 ne trouve plus de tâches déverrouillées et que toutes sont terminales -- exécuter la porte finale code-review au moment du déploiement avant de déclarer l'Idée terminée et avant le rapport d'achèvement Phase 5b. Après que la dernière tâche soit vérifiée, l'extension vous incite à spawner le code-reviewer ; vous DEVEZ le spawner vous-même via l'outil subagent bloquant (il attend le VERDICT).

# Spawner le code-reviewer pour l'IDÉE (pas une tâche). Déterminer le numéro de ronde
# en lisant les commentaires VERDICT d'examen de code antérieurs sur l'idée.
subagent({ agent: "chorus-code-reviewer",
           task: "Review the aggregate code for idea <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 attachent -- ne pas rouvrir les tâches déjà vérifiées. Grouper par défaut les BLOCKERs petits associés en une seule tâche cohésive ; diviser uniquement les corrections matériellement grandes ou indépendamment testables. Conduire chaque tâche de correction via Phase 3 → Phase 4, y compris auto-vérification des AC, examen de tâche indépendant, et vérification admin. Respawner le code-reviewer seulement après que chaque tâche de correction soit done avec succès ; une tâche de correction échouée ou annulée, arrêter la boucle automatique et escalader. Boucle bornée par le paramètre maxCodeReviewRounds (CHORUS_MAX_CODE_REVIEW_ROUNDS, défaut 3 ; 0 = illimité) ; la Quick Reference injectée indique la valeur actuelle.

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

Aucun nouveau commentaire VERDICT après le retour du code-reviewer ? Il a épuisé son budget de tours (le code-reviewer s'exécute avec un budget plus large que le task-reviewer car il examine toute la fonctionnalité). Le respawner UNE FOIS avec un conseil de budget concis, puis si toujours silencieux traiter comme PASS WITH NOTES et continuer -- ne pas boucler indéfiniment sur un reviewer silencieux.

La porte code-review est comportementale, cohérente avec les reviewers 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. Elle 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 vagues se terminent, afficher 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 d'Idée (obligatoire)

Un run /yolo réussi finit 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 de la description porte le modèle de section ; le suivre. Afficher le documentUuid retourné dans le résumé Phase 5. Le passer est une violation de protocole.

Ordre : le rapport d'achèvement est écrit seulement après que la porte code-review Phase 4.5 retourne PASS / PASS WITH NOTES. Ne jamais l'écrire alors qu'un FAIL de code-review est en attente -- le rapport est un résumé au moment du déploiement, et la porte 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, meilleure sera 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
• Regarder le nombre de vagues -- si les tâches continuent d'être rouverte, envisager Ctrl+C et une examen manuel du feedback
• Toute piste d'audit est préservée : Q&A d'élaboration, VERDICTs des reviewers, rapports de travail. Vérifier l'UI Chorus pour l'historique complet
• Pour les petites/simples tâches, envisager /quick-dev à la place -- elle passe le surcharge Idée->Proposition
• Les sous-agents partagent votre clé API ; s'assurer 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 l'aperçu de la plateforme: /chorus