Chorus Yolo Skill

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

Aperçu

/chorus-yolo automatise le workflow d'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 le projet, l'idée, l'auto-élaboration, la proposition avec docs et tâches
2. Révision de Proposition -- boucle adversariale proposal-reviewer
3. Exécution -- dispatch parallèle par vagues via sous-agents Kiro
4. Vérification -- boucle adversariale task-reviewer + vérification admin 4.5. Passerelle Code-Review -- le code-reviewer examine la modification globale de l'Idée avant le déploiement (ÉCHEC → ajouter des tâches de correction → relancer)
5. Rapport -- résumé d'achèvement

/chorus-yolo <prompt>
       |
       v
  Project + Idea + Elaboration + Proposal
       |
       v
  Proposal Reviewer (auto, jusqu'à maxProposalReviewRounds)
       |
       v
  Admin Approve --> Tasks matérialisées
       |
       v
  Exécution par sous-agents par vagues
       |  (sous-agent dev + task-reviewer par tâche)
       v
  Admin Verify chaque vague --> déverrouille la suivante
       |
       v
  Code-Review Gateway (auto, jusqu'à maxCodeReviewRounds)
       |  PASS --> déploiement   |   FAIL --> ajouter fix tasks --> 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 /chorus-develop ou /chorus-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 "/chorus-yolo needs {resource}: {missing}. Use an Admin-preset API key."

Entrée

/chorus-yolo <natural language prompt>
/chorus-yolo <prompt> --project <project-uuid>

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

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 approprié :

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

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 approprié n'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 l'Idée

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

Puis la réclamer :

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

Étape 1.3 : Auto-Élaboration

En mode /chorus-yolo, l'agent génère des questions d'élaboration et y répond lui-même -- pas de questions interactives avec l'utilisateur. 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 une autre ronde d'auto-réponse avant de résoudre -- ne pas forcer une résolution sur une ambiguïté non résolue. Il n'y a pas de contrôle humain en YOLO, donc la boucle se termine selon votre jugement qu'aucun problème matériel n'est resté ouvert (plafond de 10 rounds). Les étapes 1–2 constituent une ronde ; 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 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 contrôle de confirmation humain (l'exigence de confirmation humaine qui s'applique au flux interactif /chorus-idea est explicitement levée sous l'automation /chorus-yolo) :

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

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

Étape 1.4 : Créer la Proposition

1. Détecter le mode OpenSpec. Charger la skill /chorus-openspec-aware et exécuter son contrat de détection §1. Le résultat détermine comment le reste de cette étape écrit 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 est destiné à 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 à l'étape 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>",   // OpenSpec mode
     // description: "<summary>",                                 // free-form mode
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   })

   Puis se brancher :

   2a. Mode OpenSpec (CHORUS_OPENSPEC_ACTIVE=1). Suivre /chorus-openspec-aware §3 intégralement :

   • Choisir $SLUG, exécuter openspec new change "$SLUG" (§3.1–§3.2).
   • Écrire proposal.md, design.md, et un specs/<capability>/spec.md par capacité localement sur disque (§3.3). AJOUT de Requirements uniquement ; par spec recourir au Markdown free-form si MODIFIÉ/SUPPRIMÉ est nécessaire.
   • Définir les helpers $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 /chorus-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 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 /chorus-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é 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 les brouillons de tâches progressivement (utiliser le draftUuid retourné pour le chaînage des dépendances). acceptanceCriteriaItems est obligatoire sur chaque brouillon -- au moins un critère non-vide, sinon l'appel est rejeté :

   # First task
   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 },
       // ...
     ]
   })
   
   # Second task, depends on first
   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, le hook postToolUse injecte une notification pour spawn le sous-agent chorus-proposal-reviewer. Vous DEVEZ le spawner vous-même en premier plan -- il n'est PAS lancé automatiquement.

Phase 2 : Boucle de Révision de Proposition

Après chorus_pm_submit_proposal, le hook postToolUse injecte une notification pour spawn le chorus-proposal-reviewer. Vous DEVEZ le spawner manuellement comme un sous-agent en lecture seule en premier plan. 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 selon 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. Passer à 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 aborder chaque BLOCKER, puis resoumetttre :

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

     Après resoumission, le hook injecte la notification à nouveau -- spawner le reviewer vous-même pour le Round 2.

3. Max rounds : Boucler jusqu'à maxProposalReviewRounds (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 reviewer ? Le reviewer a épuisé son budget de tours. Le respawner 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 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 dans l'ordre des dépendances par vagues en utilisant les sous-agents Kiro. Si le spawning de sous-agent est indisponible, basculer sur l'exécution par l'agent principal.

Principal : Sous-agents Kiro (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  # All complete

  if no unblocked tasks and some tasks not done:
    # Stuck -- tasks failed review and can't proceed
    break with escalation report

  # 2. Spawner un sous-agent pour chaque tâche déverrouillée (Kiro permet jusqu'à 4 concurrents).
  #    Vous avez `subagent` dans vos outils. Pour chaque tâche, dispatcher un sous-agent
  #    développeur avec le UUID de tâche + UUID de projet + un sessionUuid, en le
  #    instruisant de suivre le workflow /chorus-develop :
  #      "Your Chorus task UUID: {task.uuid}. Project UUID: {project-uuid}.
  #       Session UUID: {fresh-session-uuid}. Implement the task per its
  #       description and acceptance criteria. Follow /chorus-develop. Read the
  #       task, proposal, and project documents for context."
  #    Si plus de 4 tâches sont déverrouillées, dispatcher par lots de 4.

  # 3. Attendre la fin de tous les sous-agents
  #    Chaque sous-agent suit /chorus-develop :
  #    claim -> in_progress -> develop -> report -> self-check AC -> submit_for_verify
  #    Après chaque submit_for_verify, le hook postToolUse de l'agent principal
  #    injecte une notification pour spawn le task-reviewer (géré en Phase 4).

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

Ce que chaque prompt de sous-agent doit contenir :

• UUID de Tâche(s) + UUID de Projet
• Un sessionUuid à passer à chorus_update_task / chorus_report_work
• L'instruction de suivre le workflow /chorus-develop

Basculement : Agent Principal (séquentiel)

Si le spawning de sous-agent échoue (indisponible, permission refusée, ou les sous-agents plantent à plusieurs reprises), basculer sur l'exécution des tâches séquentiellement comme l'agent principal :

for each task in unblocked:
  # Follow the /chorus-develop workflow directly as main agent
  chorus_claim_task({ taskUuid: "<task-uuid>" })
  chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })

  # ... implement the task: read context, write code, run 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: "..." })

  # postToolUse hook injects the task-reviewer nudge — you must spawn it yourself
  # Proceed to Phase 4 verification for this task before moving to next

Le basculement est plus lent (séquentiel, non parallèle) mais complète toujours le pipeline. Le hook postToolUse injecte des notifications de 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":
    # Subagent may have failed; skip or handle
    continue

  # 2. Spawner le sous-agent chorus-task-reviewer en PREMIER PLAN (le hook l'a notifié --
  #    vous devez le spawner vous-même). Attendre le VERDICT avant de continuer.
  #    Prompt: "Review task <task-uuid>. Round: N."

  # 3. Lire le VERDICT du task-reviewer
  comments = chorus_get_comments({ targetType: "task", targetUuid: "<task-uuid>" })
  # Find the most recent comment containing "VERDICT:"

  # 4. Agir selon le VERDICT -- trois résultats possibles :
  if VERDICT is "PASS":
    # All AC verified, no issues. Mark AC and verify.
    chorus_mark_acceptance_criteria({
      taskUuid: "<task-uuid>",
      criteria: [
        { uuid: "<ac-uuid>", status: "passed", evidence: "<from reviewer>" },
        // ...
      ]
    })
    chorus_admin_verify_task({ taskUuid: "<task-uuid>" })
    # Task is now "done" -- unblocks dependents

  if VERDICT is "PASS WITH NOTES":
    # All AC verified, minor non-blocking notes. Still mark AC and verify.
    chorus_mark_acceptance_criteria({ ... })
    chorus_admin_verify_task({ taskUuid: "<task-uuid>" })

  if VERDICT is "FAIL":
    # BLOCKERs found. Do NOT verify. Reopen for rework.
    chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
    # Task returns to "open", will be picked up in next wave

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

Max rounds par tâche : Suivi par maxTaskReviewRounds (par défaut 3). Si une tâche a été rouverte maxRounds fois, la sauter 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 l'intégralité du pipeline pour une tâche bloquée.

Pas de nouveau commentaire VERDICT après le retour du task-reviewer ? Il a épuisé son budget de tours. Le respawner UNE FOIS avec un indice de budget concis : "Stay within turn budget. Skip deep verification. Fetch task/proposal/comments, demand the developer's run evidence, 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 : Passerelle Code-Review (obligatoire avant 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 passerelle finale de code-review 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 la vérification de la dernière tâche, le hook postToolUse injecte un rappel pour spawner le code-reviewer ; vous DEVEZ le spawner vous-même en premier plan.

# Spawner le sous-agent chorus-code-reviewer pour l'IDÉE (pas une tâche). Déterminer le
# numéro de round en lisant les commentaires VERDICT de code-review antérieurs sur l'idée.
#   Prompt: "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>" })
# Find the most recent comment containing "VERDICT:"

Agir selon le VERDICT :

• PASS / PASS WITH NOTES -- la feature est autorisée à être déployée. Passer à la Phase 5 / 5b.
• FAIL -- ne PAS déployer. Lire les BLOCKERs, puis les corriger via le workflow quick-dev (/chorus-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. Piloter les tâches de correction via la Phase 3 (exécuter) → Phase 4 (vérifier), puis respawner le code-reviewer pour le prochain round. Boucle bornée par maxCodeReviewRounds (par défaut 3 ; 0 = illimité).

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

Pas de 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 grand que le task-reviewer car il examine la feature entière). Le respawner UNE FOIS avec un indice de budget concis, puis s'il est toujours silencieux traiter comme PASS WITH NOTES et continuer -- ne pas boucler indéfiniment sur un reviewer silencieux.

La passerelle code-review est comportementale, cohérente avec les reviewers de proposition/tâche : son verdict est consultatif et ne change pas le statut stocké de l'Idée. L'orchestrateur /chorus-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 feature avec un FAIL en suspens.

Phase 5 : Rapport

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

## /chorus-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)

Une exécution réussie de /chorus-yolo 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 template de section ; le suivre. Exposer le documentUuid retourné dans le résumé de la Phase 5. Sauter c'est une violation du protocole.

Ordre : le rapport d'achèvement est écrit uniquement après le retour de la passerelle code-review de la Phase 4.5 sur PASS / PASS WITH NOTES. Ne jamais l'écrire si un FAIL de code-review est en suspens -- le rapport est un résumé au moment du déploiement, et la passerelle est ce qui autorise la feature à être déployée.

Gestion d'Erreurs

Conseils

• Garder 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 contrôle de qualité -- s'il continue d'échouer, le prompt peut être trop vague
• Surveiller le nombre de vagues -- si les tâches continuent d'être rouviertes, considérer Ctrl+C et une révision manuelle du feedback
• Toute la piste d'audit est préservée : Q&R d'élaboration, VERDICTs de reviewer, rapports de travail. Vérifier l'interface utilisateur de Chorus pour l'historique complet
• Pour les petites/simples tâches, envisager /chorus-quick-dev à la place -- elle saute les frais généraux Idée->Proposition
• Les sous-agents partagent votre clé API ; s'assurer qu'elle a les permissions listées dans les Prérequis avant de commencer

Suivant

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