Quick Dev Skill

Contournez le pipeline complet AI-DLC (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 de manière autonome leur travail de développement et vérifient l'achèvement des tâches à travers des critères d'acceptation structurés.

Espace de noms des outils : Les outils Chorus sont exposés par le serveur MCP connecté avec un préfixe mcp__chorus__ sur dsh (par exemple mcp__chorus__chorus_create_tasks). Les noms simples sont utilisés ci-dessous pour la lisibilité — prépendez mcp__chorus__ lors de l'invocation. Voir chorus pour la règle complète.

Aperçu

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

vérifier permission task:admin explicite → créer/revendiquer → implémenter → auto-vérification AC → soumettre → révision tâche indépendante → vérifier ou transférer

Utilisez Quick Dev quand :

Corrections de bogues avec étapes de reproduction claires
Petites fonctionnalités (< 2 story points)
Correctifs post-livraison et comblage de lacunes après la fin des tâches d'une proposition
Tâches prototypes ou exploratoires
Correctifs urgents qui ne peuvent pas attendre l'examen de la proposition

N'utilisez PAS Quick Dev quand :

La fonctionnalité nécessite un PRD ou un document de conception technique
Plusieurs tâches interdépendantes nécessitent une planification préalable
L'élaboration par les parties prenantes est nécessaire pour clarifier les exigences
Le travail impacte l'architecture ou les composants partagés de manière significative

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

Pré-vol : Vérification des permissions

Appelez chorus_checkin et inspectez les permissions effectives de l'agent actif. Définissez canVerifyTask à true uniquement quand chorus_checkin().agent.permissions.task contient explicitement "admin" (la permission task:admin).

Ne déduisez jamais l'autorité de vérification du nom, de la persona, de l'étiquette preset/rôle, de la propriété de la tâche ou de la disponibilité des outils de l'agent. Ne demandez pas à l'utilisateur de choisir : la permission explicite détermine le chemin terminal.

Outils

Outil	Objectif
`chorus_create_tasks`	Créer une ou plusieurs tâche(s) — omettez `proposalUuid` pour une Quick Task autonome, ou transmettez-le pour l'attacher à une proposition existante
`chorus_update_task`	Éditer 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 le lot entier si une tâche en manque). Ceux-ci sont aussi la base 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 AC vagues comme « fonctionne correctement » vont à l'encontre du but ; préférez « retourne 200 sur GET /api/foo avec un token valide ».

chorus_create_tasks({
  projectUuid: "<project-uuid>",
  tasks: [{
    title: "Fix login redirect loop on Safari",
    description: "Safari loses session cookie after redirect...",
    priority: "high",
    storyPoints: 1,
    acceptanceCriteriaItems: [
      { description: "Login works on Safari 17+", required: true },
      { description: "Existing Chrome/Firefox behavior unchanged", required: true }
    ]
  }]
})

proposalUuid est optionnel :

Omettez pour les quick tasks autonomes (corrections de bogues, correctifs d'urgence, travail exploratoire)
Transmettez pour attacher la tâche à une proposition existante — utile pour le comblage de lacunes, les correctifs de suivi ou la continuation du travail après la livraison des tâches initiales d'une proposition

Étape 2 : Revendiquer la tâche

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

Étape 3 : Éditer 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 requiert), mais mettez-les à jour quand 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: "Updated with more details...",
  acceptanceCriteriaItems: [
    { description: "Login works on Safari 17+", required: true },
    { description: "Added CSRF token handling", required: true }
  ],
  addDependsOn: ["<other-task-uuid>"]
})

Étape 4 : Commencer le travail

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

Sous-agents : créez d'abord votre propre session (manuelle sur dsh — voir develop-chorus), puis transmettez 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: "Fixed Safari cookie issue:\n- Root cause: SameSite=Strict incompatible with redirect\n- Changed to 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: "Tested on Safari 17.2" },
    { uuid: "<ac-uuid-2>", devStatus: "passed", devEvidence: "Chrome/Firefox regression tests pass" }
  ]
})

Étape 7 : Soumettre et exécuter la révision indépendante

chorus_submit_for_verify({
  taskUuid: "<task-uuid>",
  summary: "Fixed Safari login redirect loop. Changed SameSite cookie policy. All AC passed."
})

Soumettre n'est pas une vérification finale. Lancez la skill task-reviewer requise via subagent avec run_in_background: false (premier plan — l'appel attend et retourne le verdict en ligne ; votre décision de vérification/réouverture en dépend) comme décrit dans develop-chorus, et lisez le commentaire Task VERDICT: le plus récent. (Définissez run_in_background: true uniquement quand vous voulez délibérément distribuer et récupérer le verdict plus tard.) PASS et PASS WITH NOTES continuent. Sur FAIL, ne vérifiez pas ou ne transférez pas : corrigez chaque BLOCKER non résolu, répétez l'auto-vérification et la soumission des AC, puis exécutez une révision tâche indépendante fraîche.

Étape 8 : Vérification sensible aux permissions

Avec task:admin explicite, après que chaque auto-vérification AC requise réussisse et que la révision indépendante n'ait aucun BLOCKER non résolu, vérifiez et continuez de manière autonome :

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

Sans task:admin explicite, n'appelez pas l'outil admin. Publiez un commentaire riche en preuves sur la tâche contenant les résultats AC, les preuves de test, le verdict de révision indépendante le plus récent et l'action exacte demandée. @mentionnez la personne responsable (préférez chorus_checkin().agent.owner) pour effectuer la vérification admin, puis terminez le tour actuel.

Ce transfert s'applique aux sessions interactives et daemon headless. N'envoyez pas une simple invite interactive en texte brut, ne demandez pas de réponse humaine ou ne comptez que sur des notifications génériques.

Intégration de session

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

Agent principal : créer des quick tasks, les traiter vous-même ou transmettre les UUIDs de tâches aux sous-agents
Sous-agents : créer votre propre session (chorus_create_session), checkin/checkout par tâche, transmettre sessionUuid à chorus_update_task / chorus_report_work et fermer la session à la sortie — voir develop-chorus pour le protocole manuel complet

dsh n'a pas de primitive Agent Teams / TeamCreate ; si vous devez exécuter plusieurs quick tasks, traitez-les séquentiellement comme l'agent principal (ou lancez des sous-agents génériques un par un).

Conseils

Gardez les Quick Tasks petites — si vous avez besoin de plus de 2-3 tâches, considérez l'utilisation de proposal-chorus
Les critères d'acceptation sont requis au moment de la création — chorus_create_tasks rejette les tâches sans eux. Ils sont votre contrat d'auto-vérification ; les AC spécifiques et testables permettent la vérification autonome et rendent le flux de travail entier autonome
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
Transmettez proposalUuid pour attacher les tâches de suivi ou de comblage de lacunes à une proposition existante — cela garde le travail connexe groupé 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 avec task:admin explicite continuent de manière autonome après que les AC et la révision indépendante réussissent ; tous les autres utilisent le transfert asynchrone humain riche en preuves

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

quick-dev-chorus