Skill Yolo

Pipeline IA entièrement automatisé. L'utilisateur fournit une seule requête ; vous gérez l'intégralité du cycle de vie : Idée -> Élaboration -> Proposition -> Examen -> Exécution -> Vérification -> Fin. Aucune requête interactive, aucun humain dans la boucle sauf si le pipeline bloque.

Ce skill est framework-agnostique : il ne suppose jamais un harness d'agent spécifique. Chaque reviewer et worker est décrit comme « spawn un sous-agent » avec un ou deux exemples concrets, et chaque étape a un fallback single-agent en ligne pour que le pipeline se termine même si les sous-agents ne sont pas disponibles.

Aperçu

Vous prenez une description en langage naturel de ce qu'il faut construire, et vous gérez tout :

1. Planification — résoudre/créer un projet, créer une Idée, auto-élaboration, brouillon de Proposition (doc de conception technique + DAG de tâches), validation, soumission.
2. Examen de la Proposition — boucle d'examen adversarial contre le skill proposal-reviewer-chorus.
3. Exécution — dispatch de tâches par vagues, ordonné par dépendances.
4. Vérification — boucle d'examen adversarial contre le skill task-reviewer-chorus + approbation admin.
5. Rapport — résumé d'achèvement + rapport obligatoire d'achèvement d'Idée.

<prompt>
   |
   v
Projet + Idée + Auto-élaboration + Proposition
   |
   v
Boucle d'examen de Proposition  (jusqu'à maxProposalReviewRounds, défaut 3)
   |   PASS / PASS WITH NOTES -> approuve ;  FAIL -> rejette + révise + resoumets
   v
Approbation Admin  -->  Documents + Tâches se matérialisent (les tâches arrivent en `open`)
   |
   v
Exécution par vagues  --  chorus_get_unblocked_tasks
   |   dispatch un worker sub-agent par tâche débloquée (fallback: sequential main agent)
   v
Boucle de Vérification  (jusqu'à maxTaskReviewRounds, défaut 3)
   |   PASS / PASS WITH NOTES -> marquer AC + vérifier ;  FAIL -> réouvrir
   |   verify débloque les dépendants -> revenir à Exécution
   v
Fin  -->  Résumé du rapport + rapport obligatoire d'achèvement d'Idée

Trappe de secours : Interrompez à tout moment. Chaque entité créée (projet, idée, proposition, tâches, commentaires) persiste dans Chorus. Reprenez manuellement via develop-chorus ou review-chorus.

URL de base : Les fichiers du skill sont hébergés sous <BASE_URL>/skill/. L'utilisateur fournit l'URL d'accès à Chorus (par ex. https://chorus.acme.com ou http://localhost:8637), dénommée <BASE_URL> ci-dessous. Consultez le skill chorus (<BASE_URL>/skill/chorus/SKILL.md) pour l'aperçu de la plateforme et les outils partagés.

Prérequis

Yolo touche chaque ressource et agit en tant que PM, développeur ET admin. La clé API DOIT avoir write + admin sur les ressources qu'il pilote :

Vérification préalable des permissions — exécutez ceci avant tout :

perms = chorus_checkin().agent.permissions
need = { idea:    ["write"],
         proposal:["write", "admin"],
         task:    ["write", "admin"],
         project: ["write"] }

missing = []
for resource, actions in need:
  for a in actions:
    if a not in (perms[resource] or []):
      missing.append(f"{resource}:{a}")

if missing:
  ABORT "yolo requires the following permissions, which this API key lacks: "
        + ", ".join(missing)
        + ". Use an Admin-preset API key (all 15 permissions) and retry."

Listez toutes les paires manquantes resource:action dans le message d'abandon — ne vous arrêtez pas à la première — afin que l'utilisateur puisse corriger la clé en une seule fois. Ne dégradez pas silencieusement ni ne sautez les phases si une permission manque ; interrompez correctement.

Entrée

<prompt en langage naturel de ce qu'il faut construire>
<prompt>   (avec un indice optionnel de projet existant, par ex. un UUID ou nom de projet)

• prompt — ce que vous voulez construire. Devient le contenu de l'Idée verbatim.
• indice de projet existant (optionnel) — un UUID ou nom de projet à réutiliser au lieu d'en créer un nouveau. S'il est absent, vous cherchez une correspondance et créez un nouveau projet uniquement si aucun ne convient.

Gardez le prompt détaillé : plus l'entrée est riche, meilleure est la proposition générée automatiquement, et moins il faut de rounds d'examen.

Flux de travail

Phase 1 : Planification

Étape 1.1 : Résoudre le Projet

Si l'utilisateur a fourni un UUID de projet :

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

Confirmez qu'il existe et réutilisez-le.

Sinon, cherchez d'abord un projet existant approprié :

# Rechercher par sujet
chorus_search({ query: "<key terms from prompt>", entityTypes: ["project"] })
# Ou lister les projets récents
chorus_list_projects()

Si un projet correspond clairement à l'intention de l'utilisateur (même sujet, actif, scope pertinent), réutilisez-le. Créez un nouveau projet uniquement si aucun ne convient :

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 réclamez-la pour en être propriétaire :

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

Étape 1.3 : Auto-élaboration (sans requêtes interactives)

En mode yolo vous générez les questions d'élaboration ET vous y répondez vous-même — il n'y a AUCUNE requête utilisateur interactive. Cela préserve une piste d'audit des décisions sans interrompre quiconque.

L'auto-élaboration est toujours une boucle. Si répondre à vos propres questions met en surface une nouvelle question, contradiction ou lacune, revenir à chorus_pm_start_elaboration pour un autre round 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 en mode yolo, donc la boucle s'arrête sur votre jugement qu'il n'y a rien de matériel en suspens (plafond de round 10). Les étapes 1–2 constituent un round ; répétez-les selon les besoins, puis résolvez 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, data model, etc.>",
         category: "functional",
         options: [
           { id: "a", label: "<option A>" },
           { id: "b", label: "<option B>" }
         ]
       }
       // ... 5-8 questions covering functional, technical, and scope aspects
     ]
   })

2. Répondre immédiatement — choisissez l'option qui convient le mieux au prompt et enregistrez votre justification :

   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 d'idée 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 mandate déjà une clé Admin-preset dans les Prérequis, donc c'est satisfait. Pour ouvrir un autre round d'auto-élaboration au lieu de résoudre, appelez simplement chorus_pm_start_elaboration à nouveau.

Étape 1.4 : Créer la Proposition

1. Créer le conteneur de proposition vide :

   chorus_pm_create_proposal({
     projectUuid: "<project-uuid>",
     title: "<feature name>",
     description: "<summary derived from the elaborated idea>",
     inputType: "idea",
     inputUuids: ["<idea-uuid>"]
   })

2. Ajouter un brouillon de document de conception technique. Capturez l'architecture, le modèle de données, la surface API et les contrats de modules (formats de retour, motifs d'erreur, points d'appel) pour que chaque brouillon de tâche puisse référencer une seule source de vérité :

   chorus_pm_add_document_draft({
     proposalUuid: "<proposal-uuid>",
     type: "tech_design",
     title: "Tech Design: <feature>",
     content: "<markdown tech design: architecture, data model, API, module contracts>"
   })

3. Ajouter des brouillons de tâches progressivement et les enchaîner dans un DAG dependsOn avec le draftUuid retourné de chaque brouillon amont. acceptanceCriteriaItems est obligatoire sur chaque brouillon — au moins un critère non vide, ou l'appel est rejeté. Chaque critère doit être objectivement vérifiable par un agent différent :

   # Première tâche
   result1 = chorus_pm_add_task_draft({
     proposalUuid: "<proposal-uuid>",
     title: "<module name>",
     description: "<what to build, referencing the 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: [ { description: "...", required: true } ],
     dependsOnDraftUuids: ["<result1.draftUuid>"]
   })

   Pour un DAG de 4 ou plus de tâches, incluez au moins une tâche de checkpoint d'intégration dont l'AC exige l'exécution bout à bout des modules précédents ensemble. Le reviewer de proposition traite un checkpoint d'intégration manquant comme un BLOCKER, donc ajoutez-en un d'avance.

4. Valider et corriger toute erreur signalée avant de soumettre :

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

5. Soumettre pour examen :

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

   Passez à la Phase 2 — vous pilotez vous-même l'examen de la proposition ; rien ne l'examine automatiquement.

Phase 2 : Boucle d'examen de Proposition

Exécutez un examen adversarial sur la proposition soumise en utilisant le motif d'Examen Indépendant (voir ci-dessous). Bouchez jusqu'à ce que le verdict permette l'approbation ou que vous épuisiez maxProposalReviewRounds.

Motif d'Examen Indépendant (framework-agnostique). Spawn un sous-agent en lecture seule et faites-le charger le skill proposal-reviewer-chorus (<BASE_URL>/skill/proposal-reviewer-chorus/SKILL.md), passer-lui le proposalUuid et le numéro du round d'examen actuel, et l'instruire de poster exactement un commentaire VERDICT sur la proposition. L'unique effet secondaire du reviewer est ce commentaire ; il n'effectue aucune écriture sur votre projet. Après son retour, lisez le verdict via chorus_get_comments.

Le mécanisme exact de spawn est spécifique au harness — ce sont des EXEMPLES seulement, pas une dépendance dure :

• Claude Code : dispatcher un sous-agent avec l'outil Task/Agent, montant le skill proposal-reviewer-chorus.
• Codex : spawn_agent montant le skill, puis wait_agent ; libérez le slot de thread avec close_agent après.
• Tout autre harness : quel que soit le primitif de sous-agent en lecture seule qu'il expose.

Fallback d'auto-examen en ligne (aucun sous-agent disponible). Si votre harness ne peut pas spawn un sous-agent, effectuez l'examen en ligne en tant qu'agent principal : lisez proposal-reviewer-chorus, suivez sa procédure contre cette proposition (récupérez la proposition section: "full", l'idée et l'élaboration ; vérifiez les documents et brouillons de tâches ; classifiez les résultats comme BLOCKER vs NOTE), et postez votre propre commentaire VERDICT via chorus_add_comment. La sémantique du verdict ci-dessous est identique dans les deux cas.

C'est le motif canonique ; chorus (<BASE_URL>/skill/chorus/SKILL.md) le documente canoniquement — décrivez-le en ligne ici pour que yolo soit auto-contenu.

Boucle d'examen :

round = 1
loop:
  # 1. Spawn le reviewer (motif d'Examen Indépendant ci-dessus) avec proposalUuid + round.
  #    Fallback: auto-examen en ligne en tant qu'agent principal.

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

  # 3. Agir sur le verdict (trois résultats).

1. VERDICT: PASS ou VERDICT: PASS WITH NOTES — approuver. Les tâches et documents se matérialisent automatiquement ; passer à la Phase 3.

   chorus_admin_approve_proposal({
     proposalUuid: "<proposal-uuid>",
     reviewNote: "PASS from reviewer. <one-line summary of any NOTES>"
   })

2. VERDICT: FAIL — lire les BLOCKERs du commentaire du reviewer, rejeter, réviser et resoumettrez :

   chorus_pm_reject_proposal({
     proposalUuid: "<proposal-uuid>",
     reviewNote: "FAIL from reviewer. Fixing BLOCKERs: <list>"
   })
   # Réviser les brouillons pour adresser chaque BLOCKER :
   #   chorus_pm_update_document_draft({ ... })
   #   chorus_pm_update_task_draft({ ... })
   chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })
   round += 1
   # Relancer l'Examen Indépendant pour le round suivant (passer round = numéro actuel).

3. Escalade de max rounds. Bouchez jusqu'à maxProposalReviewRounds (défaut 3). Si épuisé avec des BLOCKERs non résolus :

   STOP: "Proposal review failed after 3 rounds. Remaining BLOCKERs: <list>.
          Human review needed. Proposal UUID: <proposal-uuid>."

4. Pas de commentaire VERDICT après le retour du reviewer ? Le reviewer a probablement épuisé son budget de tours. Respawn-le une fois avec un indice de budget concis : "Stay within turn budget. Fetch the proposal + comments + idea only, skim for obvious BLOCKERs, and post your VERDICT within the first ~10 turns." Si la deuxième tentative ne poste toujours pas de VERDICT, traitez la proposition comme PASS WITH NOTES et procédez — le pipeline ne doit pas boucler indéfiniment sur un reviewer silencieux.

Phase 3 : Exécution (par vagues)

Après approbation, les tâches existent en open. Exécutez-les en vagues ordonnées par dépendances. Une vague est l'ensemble actuel de tâches débloquées ; vérifier une vague (Phase 4) débloque la suivante.

wave = 1
loop:
  # 1. Trouver les tâches dont les dépendances sont toutes résolues (done/closed).
  unblocked = chorus_get_unblocked_tasks({ projectUuid: "<project-uuid>" })

  if no unblocked tasks and all tasks done:
    break   # pipeline complete

  if no unblocked tasks and some tasks not done:
    break with escalation report   # stuck: tasks failed review or are circularly blocked

  # 2. Dispatcher un worker par tâche débloquée (voir dispatch de worker ci-dessous).
  # 3. Attendre que les workers atteignent `to_verify`.
  # 4. Exécuter la vérification Phase 4 pour les tâches de cette vague.
  wave += 1
  # 5. Boucle: vérifier à nouveau chorus_get_unblocked_tasks pour les tâches nouvellement débloquées.

Dispatch de worker (framework-agnostique). Pour chaque tâche débloquée, dispatcher un worker sub-agent qui suit le flux de travail du développeur (develop-chorus, <BASE_URL>/skill/develop-chorus/SKILL.md) : claim -> in_progress -> implement -> report_work -> self-check AC -> submit_for_verify. La requête du worker a besoin de :

• taskUuid (obligatoire)
• projectUuid (obligatoire, pour les recherches de contexte)
• Une instruction explicite de suivre le skill develop-chorus et de sortir après chorus_submit_for_verify pour que l'agent principal puisse exécuter la vérification.

Le mécanisme de spawn est spécifique au harness — EXEMPLES seulement :

• Claude Code : un sous-agent par tâche via l'outil Task/Agent (parallèle au sein de la vague).
• Codex : spawn_agent par tâche, puis wait_agent ; close_agent chaque worker après son retour.
• Optionnellement créer un chorus_create_session par worker pour l'observabilité et le chorus_close_session quand le worker termine.

Fallback d'agent principal séquentiel. Si les sous-agents ne sont pas disponibles, ou si l'exécution parallèle n'est pas pratique (limites de débit, budget de tokens, débogage plus simple), exécutez chaque tâche débloquée vous-même, séquentiellement, en tant qu'agent principal :

for each task in unblocked:
  chorus_claim_task({ taskUuid: "<task-uuid>" })
  chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })
  # ... read context (task, proposal documents, upstream deps), implement, 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: "..." })
  # Puis exécuter la vérification Phase 4 pour cette tâche avant de passer à la suivante.

Le fallback est plus lent (pas de parallélisme) mais termine le même pipeline.

Phase 4 : Boucle de Vérification

Après que les workers de chaque vague atteignent to_verify, vérifiez leurs tâches en utilisant le motif d'Examen Indépendant — le même mécanisme neutre que Phase 2, pointé sur le skill task-reviewer-chorus.

Motif d'Examen Indépendant (framework-agnostique). Spawn un sous-agent en lecture seule et faites-le charger le skill task-reviewer-chorus (<BASE_URL>/skill/task-reviewer-chorus/SKILL.md), passer-lui le taskUuid et le numéro du round d'examen actuel, et l'instruire de poster exactement un commentaire VERDICT sur la tâche. L'unique effet secondaire du reviewer sur le projet est ce commentaire (il peut exécuter des tests/build/lint en lecture seule, mais n'effectue jamais d'écritures). Après son retour, lisez le verdict via chorus_get_comments.

Le mécanisme exact de spawn est spécifique au harness — EXEMPLES seulement :

• Claude Code : dispatcher un sous-agent en lecture seule avec l'outil Task/Agent, montant le skill task-reviewer-chorus.
• Codex : spawn_agent montant le skill, puis wait_agent ; close_agent après pour libérer le slot de thread.

Fallback d'auto-examen en ligne (aucun sous-agent disponible). Effectuez l'examen en ligne en tant qu'agent principal : lisez task-reviewer-chorus, suivez sa procédure (récupérez la tâche, son AC, les commentaires et la proposition section: "documents" ; exécutez les test/build/lint du projet ; vérifiez chaque AC indépendamment ; classifiez BLOCKER vs NOTE), et postez votre propre commentaire VERDICT via chorus_add_comment.

Boucle de vérification, par tâche de la vague :

for each task in wave_tasks:
  t = chorus_get_task({ taskUuid: "<task-uuid>" })
  if t.status != "to_verify":
    continue   # worker did not submit; handle in a later wave or escalate

  # Spawn le task reviewer (motif d'Examen Indépendant) avec taskUuid + round.
  # Fallback: auto-examen en ligne.

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

Agissez sur le verdict — trois résultats :

1. VERDICT: PASS — tous les AC vérifiés, aucun problème. Marquer l'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>" })   # -> done, unblocks dependents

2. VERDICT: PASS WITH NOTES — notes mineures non bloquantes uniquement. Toujours marquer l'AC et vérifier (mêmes deux appels qu'au-dessus).

3. VERDICT: FAIL — BLOCKERs trouvés. Ne PAS vérifier. Réouvrir pour rework ; la tâche revient en in_progress (son AC réinitialisée en pending) et est reprise à la prochaine vague :

   chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
   chorus_add_comment({ targetType: "task", targetUuid: "<task-uuid>",
                        content: "Reopened. BLOCKERs to fix: <list>" })

Escalade de max rounds. Suivre les rounds d'examen par tâche via maxTaskReviewRounds (défaut 3). Si une tâche a été rouverte 3 fois et échoue toujours, la passer et la signaler pour escalade humaine — ne pas arrêter tout le pipeline pour une tâche bloquée :

ESCALATE: "Task '<title>' failed review after 3 rounds. Last BLOCKERs: <list>.
           Manual intervention needed. Task UUID: <task-uuid>."

Pas de commentaire VERDICT après le retour du reviewer ? Il a épuisé son budget de tours. Respawn-le une fois avec un indice de budget concis : "Stay within turn budget. Fetch the task/proposal/comments, run only the core tests, and post your VERDICT within the first ~12 turns." Si la deuxième tentative ne poste toujours pas de VERDICT, traitez comme PASS WITH NOTES et procédez — ne pas boucler indéfiniment.

Après vérification de chaque tâche de la vague, retourner à la Phase 3 et relancer chorus_get_unblocked_tasks pour les tâches nouvellement débloquées. Répétez jusqu'à ce qu'aucune tâche ne reste.

Phase 5 : Rapport

Quand toutes les vagues se terminent, générez 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
- Idea Completion Report: <document-uuid>   (from Phase 5b)

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

Une exécution yolo réussie termine toujours l'Idée. Appelez chorus_create_report exactement une fois, avec proposalUuid défini à la dernière proposition vérifiée. La description de l'outil lui-même porte le modèle de section — suivez-le. Surfacez le documentUuid retourné dans le tableau résumé Phase 5. Passer ceci est une violation de protocole.

result = chorus_create_report({
  proposalUuid: "<last-verified-proposal-uuid>",
  // ... follow the tool description's section template ...
})
# Surface result.documentUuid in the Phase 5 summary.

Gestion des erreurs

Conseils

• Gardez le prompt détaillé — une entrée plus riche produit une proposition plus forte et moins de rounds d'examen.
• Le reviewer de proposition est votre porte de qualité — les FAILs répétés signifient généralement que le prompt est trop vague ; affinez-le et relancez.
• Surveillez le nombre de vagues — si les tâches continuent d'être rouverte, interrompez et inspectez les retours du reviewer avant de continuer.
• Préférez les sous-agents quand disponibles — un reviewer en lecture seule frais est plus adversarial que d'examiner votre propre résultat en ligne ; utilisez le fallback en ligne seulement si vous devez.
• Tout est audité — l'élaboration Q&A, les VERDICTs du reviewer, les rapports de travail et les approbations persistent tous ; inspectez l'interface utilisateur Chorus pour l'historique complet.
• Pour le petit travail mono-étape, préférez quick-dev-chorus (<BASE_URL>/skill/quick-dev-chorus/SKILL.md) — il saute les frais généraux Idée -> Proposition.
• Les sous-agents partagent votre clé API — confirmez qu'elle porte les permissions des Prérequis avant de commencer.

Suivant

• Pour créer des propositions manuellement : skill proposal-chorus (<BASE_URL>/skill/proposal-chorus/SKILL.md)
• Pour développer des tâches manuellement : skill develop-chorus (<BASE_URL>/skill/develop-chorus/SKILL.md)
• Pour examiner les propositions et vérifier les tâches manuellement : skill review-chorus (<BASE_URL>/skill/review-chorus/SKILL.md)
• Pour l'aperçu de la plateforme et les outils partagés : skill chorus (<BASE_URL>/skill/chorus/SKILL.md)