Skill Dev Rapide

Contournez le pipeline AI-DLC complet (Idée → Élaboration → Proposition → Approbation) et créez des tâches directement. Idéal pour les petits travaux bien compris. L'objectif est que les agents enregistrent autonomement leur travail de développement et vérifient l'accomplissement des tâches par des critères d'acceptation structurés.

Espace de noms des outils : Les outils Chorus sont exposés par le serveur MCP connecté sous un préfixe chorus__ sur OpenClaw (par ex. chorus__chorus_create_tasks). Les noms simples sont utilisés ci-dessous pour la lisibilité — préfixez chorus__ lors de l'invocation. Voir /chorus pour la règle complète.

Aperçu

Le flux AI-DLC standard assure la qualité par une planification structurée, mais ajoute une surcharge qui ralentit les petites tâches. Dev Rapide offre une alternative légère :

[vérifier rôle admin] → chorus_create_tasks → chorus_claim_task → in_progress → report → self-check AC → submit for verify → [self-verify si admin] → done

Utilisez Dev Rapide pour :

Les corrections de bugs avec étapes de reproduction claires
Les petites fonctionnalités (< 2 story points)
Les patches post-livraison et comblements de lacunes après l'accomplissement des tâches d'une proposition
Les tâches prototype ou exploratoires
Les correctifs urgents qui ne peuvent pas attendre l'examen de la proposition

N'UTILISEZ PAS Dev Rapide pour :

Les fonctionnalités qui nécessitent un PRD ou un document de conception technique
Les tâches multiples interdépendantes nécessitant une planification préalable
Les élaborations avec les parties prenantes pour clarifier les exigences
Les travaux impactant significativement l'architecture ou les composants partagés

Pour les travaux complexes, utilisez /idea + /proposal à la place.

Pré-vol : Vérification Admin Auto-Vérification

Avant de créer des tâches, si chorus_checkin().agent.permissions.task inclut "admin", posez la question à l'utilisateur (comme une invite en texte brut — OpenClaw n'a pas de AskUserQuestion) :

"Je dispose de privilèges admin. Après le développement, devrais-je vérifier la tâche moi-même, ou la laisser à un autre admin pour vérifier ? Répondez 'self' ou 'other'."

Cela a de l'importance car les agents admin peuvent appeler chorus_admin_verify_task pour fermer la boucle de manière autonome. Si l'utilisateur approuve l'auto-vérification, vous pouvez compléter le cycle entier créer → développer → vérifier sans intervention humaine. Enregistrez la décision et appliquez-la à l'étape 7.

Outils

Outil	Objectif
`chorus_create_tasks`	Créer une ou plusieurs tâche(s) — omettez `proposalUuid` pour une Quick Task autonome, ou passez-le pour l'attacher à une proposition existante
`chorus_update_task`	Modifier les champs de la tâche (titre, description, priorité, AC, dépendances) ou changer le statut
`chorus_claim_task`	Revendiquer une tâche (open → assigned)
`chorus_report_work`	Signaler la progression avec mise à jour de statut optionnelle
`chorus_report_criteria_self_check`	Auto-vérifier les critères d'acceptation avant de soumettre
`chorus_submit_for_verify`	Soumettre pour vérification admin
`chorus_admin_verify_task`	(admin uniquement) Vérifier la tâche — utiliser quand l'auto-vérification est approuvée

Flux de travail

Étape 1 : Créer une Quick Task

acceptanceCriteriaItems est obligatoire — chorus_create_tasks rejette toute tâche sans au moins un critère non vide (et rejette tout le lot si une tâche en manque). Ce sont aussi les fondations pour l'auto-vérification à l'étape 6. Écrivez des critères spécifiques et testables que vous pouvez vérifier objectivement après le développement. Les critères vagues comme "fonctionne correctement" vont à l'encontre de l'objectif ; préférez "retourne 200 sur GET /api/foo avec un token valide".

chorus_create_tasks({
  projectUuid: "<project-uuid>",
  tasks: [{
    title: "Corriger la boucle de redirection de connexion sur Safari",
    description: "Safari perd le cookie de session après redirection...",
    priority: "high",
    storyPoints: 1,
    acceptanceCriteriaItems: [
      { description: "La connexion fonctionne sur Safari 17+", required: true },
      { description: "Le comportement existant Chrome/Firefox inchangé", required: true }
    ]
  }]
})

proposalUuid est optionnel :

Omettez pour les quick tasks autonomes (corrections de bugs, hotfixes, travail exploratoire)
Passez pour attacher la tâche à une proposition existante — utile pour les comblements de lacunes, les patches de suivi, ou la continuation du travail après la livraison initiale des tâches d'une proposition

Étape 2 : Revendiquer la tâche

chorus_claim_task({ taskUuid: "<task-uuid>" })

Étape 3 : Modifier les détails (si nécessaire)

Utilisez chorus_update_task pour affiner la tâche après sa création. Les tâches ont toujours des AC (la création les exige), mais mettez-les à jour si votre compréhension change pendant le développement. Passer acceptanceCriteriaItems remplace les critères de la tâche par l'ensemble fourni non vide ; omettez le champ pour les laisser inchangés (il ne peut pas être utilisé pour effacer les AC).

chorus_update_task({
  taskUuid: "<task-uuid>",
  description: "Mise à jour avec plus de détails...",
  acceptanceCriteriaItems: [
    { description: "La connexion fonctionne sur Safari 17+", required: true },
    { description: "Ajout de la gestion des tokens CSRF", required: true }
  ],
  addDependsOn: ["<other-task-uuid>"]
})

Étape 4 : Commencer à travailler

chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })

Sub-agents : créez d'abord votre propre session (manuellement sur OpenClaw — voir /develop), puis passez sessionUuid pour l'attribution :

chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress", sessionUuid: "<session-uuid>" })

Étape 5 : Signaler la progression

chorus_report_work({
  taskUuid: "<task-uuid>",
  report: "Correction du problème de cookie Safari :\n- Cause première : SameSite=Strict incompatible avec la redirection\n- Changé en SameSite=Lax\n- Commit : abc1234",
  sessionUuid: "<session-uuid>"
})

Étape 6 : Auto-vérifier les critères d'acceptation

chorus_report_criteria_self_check({
  taskUuid: "<task-uuid>",
  criteria: [
    { uuid: "<ac-uuid-1>", devStatus: "passed", devEvidence: "Testé sur Safari 17.2" },
    { uuid: "<ac-uuid-2>", devStatus: "passed", devEvidence: "Tests de régression Chrome/Firefox réussis" }
  ]
})

Étape 7 : Soumettre pour vérification (ou auto-vérifier)

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Correction de la boucle de redirection de connexion Safari. Modification de la politique des cookies SameSite. Tous les AC réussis."
})

Auto-vérification admin : Si vous avez task: ["admin"] dans les permissions et que l'utilisateur a approuvé l'auto-vérification dans la vérification de pré-vol, vous pouvez vérifier la tâche vous-même immédiatement après la soumission :

chorus_admin_verify_task({ taskUuid: "<task-uuid>" })

Ceci complète le cycle autonome complet : créer → développer → vérifier → done.

Révision indépendante optionnelle : pour les quick tasks non triviales, vous pouvez toujours lancer le skill /task-reviewer dans un sub-agent spawnné (sessions_spawn avec une tâche lui indiquant de lancer /task-reviewer contre le taskUuid, puis attendez le VERDICT) ou faire une auto-révision en lecture seule ciblée avant de vérifier — même motif qu'à l'étape 8.5 de /develop. Il n'y a pas de hook PostToolUse sur OpenClaw, donc faites cela en ligne si vous le souhaitez.

Intégration de session

Les Quick Tasks supportent l'exécution de sub-agents tout comme les tâches basées sur les propositions. Le cycle de vie des sessions est manuel sur OpenClaw (pas de hooks SubagentStart/heartbeat/cleanup) :

Agent principal : créez des quick tasks, travaillez dessus vous-même, ou passez les UUIDs des tâches aux sub-agents
Sub-agents : créez votre propre session (chorus_create_session), checkin/checkout par tâche, passez sessionUuid à chorus_update_task / chorus_report_work, et fermez la session à la sortie — voir /develop pour le protocole manuel complet

OpenClaw n'a pas de primitif Agent Teams / TeamCreate ; si vous devez exécuter plusieurs quick tasks, travaillez-les séquentiellement comme l'agent principal (ou dispatchez des sub-agents génériques un à la fois).

Conseils

Gardez les Quick Tasks petites — si vous avez besoin de plus de 2-3 tâches, envisagez d'utiliser /proposal
Les critères d'acceptation sont obligatoires au moment de la création — chorus_create_tasks rejette les tâches sans eux. Ils sont votre contrat d'auto-vérification ; des AC spécifiques et testables permettent la vérification autonome et rendent le flux de travail entier auto-contenu
Utilisez chorus_update_task pour affiner les tâches (y compris les AC) après la création plutôt que de supprimer et recréer
Passez proposalUuid pour attacher les tâches de suivi ou de comblement de lacunes à une proposition existante — cela maintient les travaux connexes groupés dans le même contexte de projet et DAG
Les Quick Tasks apparaissent dans la même liste de tâches de projet et DAG que les tâches basées sur les propositions
Les agents admin peuvent exécuter le cycle de vie complet de manière autonome (créer → développer → auto-vérifier) — mais confirmez toujours avec l'utilisateur d'abord (invite en texte brut)

Pour les détails du cycle de vie complet des tâches, voir /develop
Pour la vérification admin, voir /review
Pour le flux de planification standard, voir /idea et /proposal
Pour un aperçu de la plateforme, voir /chorus

quick-dev