Compétence Yolo

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

Aperçu

/yolo automatise le workflow IA-DLC complet. Vous fournissez une description en langage naturel de ce que vous souhaitez construire, et l'agent gère tout :

Planification -- créer projet, idée, auto-élaboration, proposition avec docs et tâches
Révision de la proposition -- boucle adversariale proposal-reviewer
Exécution -- dispatch de tâches parallèles par vagues via spawn_agent
Vérification -- boucle adversariale task-reviewer + vérification admin
Rapport -- résumé d'achèvement

/yolo <prompt>
       |
       v
  Projet + Idée + Élaboration + Proposition
       |
       v
  Proposal Reviewer (auto, jusqu'à maxProposalReviewRounds)
       |
       v
  Admin Approve --> Les tâches se matérialisent
       |
       v
  Exécution parallèle spawn_agent par vagues
       |  (agent dev + task-reviewer par tâche)
       v
  Admin Verify chaque vague --> déverrouille la suivante
       |
       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 a besoin de droits en écriture + admin sur chaque ressource qu'elle touche :

Besoins	Raison
`idea: [write]`	Créer des idées, exécuter l'élaboration
`proposal: [write, admin]`	Créer des propositions ; les approuver
`task: [write, admin]`	Créer, exécuter, vérifier les tâches
`project: [write]`	Créer le projet s'il n'y en a pas

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 ; utilise 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 son existence et procéder.

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, périmètre pertinent), 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 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 une autre round auto-répondue avant de résoudre -- ne pas forcer une résolution sur une ambiguïté irrésolue. Il n'y a pas de barrière humaine en YOLO, donc la boucle s'arrête sur votre jugement qu'il ne reste rien de matériel ouvert (cap de round 10). Les étapes 1–2 constituent une round ; les répéter selon les besoins, puis résoudre une fois à l'étape 3.

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
  ]
})

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: ..." },
    // ...
  ]
})

Résoudre -- en mode YOLO l'agent résout l'élaboration de manière autonome, sans barrière de confirmation humaine (la condition de confirmation humaine qui s'applique au flux interactif /idea est explicitement levée en vertu de 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 aux Prérequis, donc c'est satisfait. Pour ouvrir une autre round d'auto-élaboration au lieu de résoudre, appelez simplement chorus_pm_start_elaboration à nouveau.

Étape 1.4 : Créer une proposition

Détecter le mode OpenSpec. Charger la compétence openspec-aware à ~/.codex/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 orientée spec (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.
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 à 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).
- Rédiger proposal.md, design.md, et un specs/<capability>/spec.md par capacité localement sur disque (§3.3). Uniquement les requirements ADDED ; par spec se rabattre sur le Markdown free-form si MODIFIED/REMOVED est nécessaire.
- Définir les helpers $API, json_encode_file, chorus_check_response (§3.4, §6).
- Refléter chaque fichier local via "$API" chorus_pm_add_document_draft "$PAYLOAD" (§3.6) -- un appel par fichier, avec le type de document de openspec-aware §5. (Le chorus-mcp-call.sh de Codex prend <TOOL_NAME> <JSON> directement ; pas de sous-commande mcp-tool.)
⛔ Ne pas invoquer chorus_pm_add_document_draft / chorus_pm_update_document_draft / chorus_pm_update_document depuis le harness MCP de Codex avec un champ content tapé à la main dans cette branche. Retaper le corps markdown gaspille 20k+ tokens par proposition et casse l'égalité des octets 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é 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>"
})
```

Ajouter les brouillons de tâches progressivement (utiliser le draftUuid retourné pour le chaînage de dépendances). acceptanceCriteriaItems est requis sur chaque brouillon -- au moins un critère non vide, sinon 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>"]
})

Valider :

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

Corriger les erreurs, puis procéder.

Soumettre :
```
chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })
```
Après cet appel, le hook PostToolUse injecte un contexte vous instruisant de spawner le sous-agent chorus-proposal-reviewer. Vous DEVEZ le spawner vous-même via spawn_agent et attendre son retour avec wait_agent -- il n'est PAS auto-lancé.

Phase 2 : Boucle de révision de la proposition

Après chorus_pm_submit_proposal, le hook PostToolUse injecte un contexte vous instruisant de spawner le sous-agent chorus-proposal-reviewer. Le reviewer est une SKILL, pas un agent_type intégré -- le spawner en montant la skill dans un agent par défaut :

spawn_agent(
  agent_type="default",
  items=[
    { type: "skill", name: "Chorus Proposal Reviewer", path: "chorus:chorus-proposal-reviewer" },
    { type: "text",  text: "Review proposal <proposal-uuid>. Max review rounds: 3. Post VERDICT comment." }
  ]
)
wait_agent([reviewer_id])

Puis :

Lire le VERDICT du reviewer :
```
chorus_get_comments({ targetType: "proposal", targetUuid: "<proposal-uuid>" })
```
Chercher le commentaire le plus récent contenant VERDICT:.

IMPORTANT -- libérer le slot de thread : après le retour de wait_agent, appeler immédiatement close_agent(reviewer_id). Codex plafonne les threads d'agent concurrents à 6 ; le statut completed NE libère PAS un slot -- seul close_agent le fait. Sur les longs exécutions $yolo vous ALLEZ atteindre la limite si vous ne fermez pas chaque reviewer après utilisation.
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. Procéder à 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 traiter chaque BLOCKER, puis soumettre à nouveau :
```
chorus_pm_submit_proposal({ proposalUuid: "<proposal-uuid>" })
```
  Après la resoumission, le hook injecte le contexte à nouveau -- spawner le reviewer vous-même pour la Round 2.

Max rounds : Boucler jusqu'à maxProposalReviewRounds (depuis 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>"

Pas de nouveau commentaire VERDICT après le retour du reviewer ? Le reviewer a épuisé son budget maxTurns. Le respawner UNE FOIS avec un indice 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 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 reviewer silencieux.

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

Après approbation de la proposition, les tâches existent en statut open. Les exécuter dans des vagues ordonnées par dépendances en utilisant Codex spawn_agent. Si le spawn parallèle n'est pas souhaité ou trop de workers en vol, se rabattre sur l'exécution séquentielle du main-agent.

Principal : workers parallèles `spawn_agent`

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  # Tout est complet

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

  # 2. Pour chaque tâche déverrouillée, spawner un worker
  for each task in unblocked:
    # Optionnel : créer une session Chorus pour l'observabilité
    session = chorus_create_session({ name: f"worker-{task.title[:20]}" })

    spawn_agent(
      agent_type="worker",
      message=f"""You are a Chorus developer worker. Follow the $develop skill.

      Your sessionUuid: {session.uuid}   # omit this line if no session
      Your task UUID: {task.uuid}
      Project UUID: {project_uuid}

      Implement per task description + acceptance criteria. Read task, proposal, and project documents for context. After chorus_submit_for_verify, exit and let the main agent spawn the task-reviewer."""
    )

  # 3. Attendre le retour des workers (utiliser wait_agent)
  #    Chaque worker suit la skill $develop :
  #    claim -> in_progress -> develop -> report -> self-check AC -> submit_for_verify

  # 4. Fermer les sessions worker (responsabilité du main agent jusqu'à ce que le plugin Codex câble le cleanup SubagentStop)
  for each session:
    chorus_close_session({ sessionUuid: session.uuid })

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

Ce que le prompt du worker a besoin :

taskUuid (requis)
sessionUuid (optionnel -- uniquement si le main agent en a créé un pour l'observabilité)
projectUuid (requis pour les lookups de contexte)
Instruction explicite de suivre la skill $develop -- la skill elle-même a tous les détails du workflow

Fallback : Main Agent (séquentiel)

Si le spawn parallèle n'est pas pratique (limites de débit, budget de tokens, ou débogage plus simple souhaité), se rabattre sur l'exécution séquentielle des tâches en tant que main agent :

for each task in unblocked:
  # Suivre le workflow /develop directement en tant que main agent
  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: "..." })

  # Le hook PostToolUse 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, non parallèle) mais complète toujours le pipeline. Le hook PostToolUse 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 sub-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 sub-agent peut avoir échoué ; ignorer ou gérer
    continue

  # 2. Spawner task-reviewer en FOREGROUND et attendre (utiliser wait_agent)
  #    Monter la SKILL chorus-task-reviewer dans un sub-agent par défaut
  #    (Codex n'a que les types built-in default/explorer/worker).
  spawn_agent(
    agent_type="default",
    items=[
      { type: "skill", name: "Chorus Task Reviewer", path: "chorus:chorus-task-reviewer" },
      { type: "text",  text: "Review Chorus task <task-uuid>. Post VERDICT as a comment before exit." }
    ]
  )
  wait_agent([reviewer_id])
  close_agent(reviewer_id)   # IMPORTANT: libérer le slot de thread (max 6 concurrents, completed != closed)

  # 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 VERDICT -- trois résultats possibles :
  if VERDICT is "PASS":
    # Tous les AC vérifiés, pas de problème. Marquer 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>" })
    # 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 révision.
    chorus_admin_reopen_task({ taskUuid: "<task-uuid>" })
    # La tâche retourne en "open", sera prise dans la vague suivante

Après avoir vérifié toutes les tâches de la vague, retourner à la Phase 3 pour vérifier les tâches nouvellement déverrouillées.

Max rounds par tâche : Suivi par maxTaskReviewRounds depuis la config du plugin (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 tout le pipeline pour une tâche bloquée.

Pas de nouveau commentaire VERDICT après le retour du task-reviewer ? Il a épuisé son budget maxTurns. Le respawner UNE FOIS avec un indice 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 produit aussi pas de VERDICT, traiter comme PASS WITH NOTES et procéder -- ne pas boucler indéfiniment.

Phase 4.5 : Gateway de code-review (obligatoire pré-ship)

Une fois que chaque tâche de la proposition de l'idée est vérifiée (done) -- Phase 3 ne trouve plus de tâches déverrouillées et aucune ne reste non-terminale -- exécuter la gateway finale de code-review au moment du ship avant le rapport d'achèvement de la Phase 5b. Elle révise le changement de code agrégé de l'Idée entière sur toutes les tâches (pas une seule tâche) et poste son verdict sur l'Idée. Après vérification de la dernière tâche, le hook PostToolUse injecte un rappel pour la spawner.

Le code-reviewer est une SKILL, pas un agent_type intégré -- le monter dans un sub-agent par défaut et attendre :

reviewer = spawn_agent(agent_type="default", items=[
    { type: "skill", name: "Chorus Code Reviewer", path: "chorus:chorus-code-reviewer" },
    { type: "text", text: "Review the aggregate code for idea <idea-uuid>. Round: N." }
])
wait_agent([reviewer])
close_agent(reviewer)   # libérer le slot de thread (Codex plafonne les agents concurrents à 6)

# Lire le VERDICT sur l'IDÉE
comments = chorus_get_comments({ targetType: "idea", targetUuid: "<idea-uuid>" })

Agir sur le VERDICT :

PASS / PASS WITH NOTES -- la fonctionnalité est autorisée à être livrée. Procéder à Phase 5 / 5b.
FAIL -- NE PAS livrer. 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. Les conduire via Phase 3 → Phase 4, puis respawner le code-reviewer pour la round suivante. Boucle bornée par maxCodeReviewRounds (défaut 3 ; 0 = illimité).

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

Pas de nouveau VERDICT après le retour du code-reviewer ? Il a épuisé son budget maxTurns (plus grand que celui du task-reviewer car il révise la fonctionnalité entière). Respawner UNE FOIS avec un indice concis ; si toujours silencieux, traiter comme PASS WITH NOTES et procéder.

La gateway est comportementale comme les deux autres reviewers : son verdict est consultatif et ne change pas le statut stocké de l'Idée ; l'orchestrateur l'honore. Elle s'exécute avant le rapport d'achèvement pour que le rapport ne soit jamais écrit quand un FAIL est en suspens.

Phase 5 : Rapport

Après la fin de toutes les vagues, 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 de l'Idée (obligatoire)

Une exécution réussie $yolo termine toujours l'Idée -- appeler chorus_create_report une seule 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 Phase 5. L'ignorer est une violation de protocole.

Ordre : écrire le rapport d'achèvement uniquement après le retour de la gateway de code-review de Phase 4.5 PASS / PASS WITH NOTES -- jamais quand un FAIL de code-review est en suspens.

Gestion des erreurs

Scénario	Action
Permissions manquantes au démarrage	Abandonner avec message listant les paires resource/action manquantes (voir Prérequis). Recommander une clé API Admin-preset.
Création de projet échoue	Signaler l'erreur, suggérer à l'utilisateur de créer le projet manuellement et de réessayer avec `--project`
Proposal reviewer FAIL après maxRounds	Arrêter le pipeline, signaler les BLOCKERs persistants, suggérer une révision manuelle
Task reviewer FAIL après maxRounds	Signaler la tâche comme nécessitant escalade, continuer avec d'autres tâches
Crash du sub-agent / pas de submit	Logger l'erreur, ignorer la tâche, la reprendre dans la vague suivante si possible
Ctrl+C	Toutes les entités persistent dans Chorus. L'utilisateur peut reprendre via `/develop` ou `/review`

Conseils

Garder le prompt initial détaillé -- plus le contexte fourni est complet, meilleure est la qualité de la proposition auto-générée
Le proposal-reviewer est votre gate de qualité -- s'il continue à FAILer, le prompt peut être trop vague
Surveiller le nombre de vagues -- si les tâches continuent d'être rouverte, envisager Ctrl+C et examiner manuellement les retours
Toute la piste d'audit est préservée : Q&A d'élaboration, VERDICTs du reviewer, rapports de travail. Vérifier l'UI Chorus pour l'historique complet
Pour les petites/simples tâches, envisager /quick-dev à la place -- cela saute l'overhead Idée->Proposition
Les sub-agents partagent votre clé API ; s'assurer qu'elle a les permissions listées aux Prérequis avant de démarrer

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 l'aperçu de la plateforme : /chorus

yolo

Compétence Yolo

Aperçu

Prérequis

Entrée

Workflow

Phase 1 : Planification

Étape 1.1 : Résoudre le projet

Étape 1.2 : Créer une idée

Étape 1.3 : Auto-élaboration

Étape 1.4 : Créer une proposition

Phase 2 : Boucle de révision de la proposition

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

Principal : workers parallèles `spawn_agent`

Fallback : Main Agent (séquentiel)

Phase 4 : Vérification

Phase 4.5 : Gateway de code-review (obligatoire pré-ship)

Phase 5 : Rapport

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

Gestion des erreurs

Conseils

Suivant

Skills similaires

Compétence Yolo

Aperçu

Prérequis

Entrée

Workflow

Phase 1 : Planification

Étape 1.1 : Résoudre le projet

Étape 1.2 : Créer une idée

Étape 1.3 : Auto-élaboration

Étape 1.4 : Créer une proposition

Phase 2 : Boucle de révision de la proposition

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

Principal : workers parallèles spawn_agent

Fallback : Main Agent (séquentiel)

Phase 4 : Vérification

Phase 4.5 : Gateway de code-review (obligatoire pré-ship)

Phase 5 : Rapport

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

Gestion des erreurs

Conseils

Suivant

Skills similaires

Principal : workers parallèles `spawn_agent`